A solução postada pelo bgles é excelente para mim em termos de configuração correta de permissões inicialmente (eu uso o segundo método), mas ainda tem problemas em potencial para o Laravel.
Por padrão, o Apache criará arquivos com permissões 644. Então, isso é praticamente tudo em armazenamento /. Portanto, se você excluir o conteúdo de storage / framework / views, acesse uma página pelo Apache e verá que a exibição em cache foi criada como:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Se você executar o "artisan serve" e acessar uma página diferente, obterá permissões diferentes porque o CLI PHP se comporta de maneira diferente do Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
Por si só, isso não é grande coisa, pois você não fará nada disso na produção. Mas se o Apache criar um arquivo que posteriormente precise ser gravado pelo usuário, ele falhará. E isso pode se aplicar a arquivos em cache, visualizações e logs em cache ao implantar usando um usuário conectado e artesão. Um exemplo fácil é "cache artesanal: limpar", que falhará em excluir os arquivos de cache www-data: www-data 644.
Isso pode ser parcialmente mitigado pela execução de comandos artesanais como www-data, portanto, você estará executando / scripts como:
sudo -u www-data php artisan cache:clear
Ou você evitará o tédio disso e o adicionará às suas .bash_aliases:
alias art='sudo -u www-data php artisan'
Isso é bom o suficiente e não está afetando a segurança de forma alguma. Mas em máquinas de desenvolvimento, a execução de scripts de teste e saneamento torna isso pesado, a menos que você queira configurar aliases para usar 'sudo -u www-data' para executar o phpunit e tudo o mais que você verifica nas suas compilações que pode causar a criação de arquivos.
A solução é seguir a segunda parte do conselho do bgles e adicionar o seguinte ao / etc / apache2 / envvars e reiniciar (não recarregar) o Apache:
umask 002
Isso forçará o Apache a criar arquivos como 664 por padrão. Em si, isso pode representar um risco de segurança. No entanto, nos ambientes Laravel que estão sendo discutidos aqui (Homestead, Vagrant, Ubuntu), o servidor da Web é executado como usuário www-data no grupo www-data. Portanto, se você não permitir que os usuários participem arbitrariamente do grupo www-data, não haverá riscos adicionais. Se alguém conseguir sair do servidor da Web, ele terá o nível de acesso a dados www de qualquer maneira, para que nada se perca (embora essa não seja a melhor atitude a ter em relação à segurança). Portanto, na produção, é relativamente seguro e, em uma máquina de desenvolvimento de usuário único, isso não é um problema.
Por fim, como o usuário está no grupo www-data, e todos os diretórios que contêm esses arquivos são g + s (o arquivo é sempre criado no grupo do diretório pai), qualquer coisa criada pelo usuário ou pelo www-data será r / w para o outro.
E esse é o objetivo aqui.
editar
Ao investigar a abordagem acima para definir ainda mais as permissões, ela ainda parece boa o suficiente, mas alguns ajustes podem ajudar:
Por padrão, os diretórios são 775 e os arquivos 664 e todos os arquivos têm o proprietário e o grupo do usuário que acabou de instalar a estrutura. Então, assuma que começamos a partir desse ponto.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
A primeira coisa que fazemos é bloquear o acesso a todos os outros e tornar o grupo www-data. Somente o proprietário e os membros do www-data podem acessar o diretório.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Para permitir que o servidor web crie services.json e compiled.php, conforme sugerido pelo guia de instalação oficial do Laravel. Definir o bit fixo do grupo significa que eles pertencerão ao criador com um grupo de www-data.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Fazemos o mesmo com a pasta de armazenamento para permitir a criação de cache, log, sessão e exibição de arquivos. Usamos o find para definir explicitamente as permissões de diretório de maneira diferente para diretórios e arquivos. Não precisamos fazer isso no bootstrap / cache, pois não há (normalmente) nenhum subdiretório lá.
Pode ser necessário reaplicar qualquer sinalizador executável e excluir vendor / * e reinstalar as dependências do compositor para recriar links para phpunit et al, por exemplo:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
É isso aí. Exceto pelo umask para o Apache explicado acima, isso é tudo o que é necessário sem tornar toda a inicialização do projeto gravável por www-data, que é o que acontece com outras soluções. Portanto, é marginalmente mais seguro dessa maneira, pois um invasor executando como www-data tem acesso de gravação mais limitado.
finalizar edição
Alterações para Systemd
Isso se aplica ao uso de php-fpm, mas talvez outros também.
O serviço systemd padrão precisa ser substituído, o umask definido no arquivo override.conf e o serviço reiniciado:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777é muita liberdade, porque inclui todas as permissões para todos.