Como configurar permissões de arquivo para o Laravel?

Estou usando o Apache Web Server com o proprietário definido _www:_www. Nunca sei qual é a melhor prática com permissões de arquivo, por exemplo, quando crio o novo projeto do Laravel 5.

O Laravel 5 requer que a /storagepasta seja gravável. Eu encontrei muitas abordagens diferentes para fazê-lo funcionar e geralmente termino fazendo-o 777chmod recursivamente. Sei que não é a melhor ideia.

O documento oficial diz:

O Laravel pode exigir que algumas permissões sejam configuradas: pastas dentro storagee vendorexigir acesso de gravação pelo servidor da web.

Isso significa que o servidor da Web também precisa acessar as próprias pastas storagee vendorou apenas o conteúdo atual?

Presumo que o que é muito melhor, está mudando o proprietário em vez de permissões. Alterei recursivamente todas as permissões de arquivos do Laravel _www:_wwwe isso fez o site funcionar corretamente, como se eu tivesse mudado o chmod para 777. O problema é que agora meu editor de texto solicita uma senha sempre que eu quero salvar qualquer arquivo e o mesmo acontece se eu tentar alterar alguma coisa no Finder, como por exemplo copiar um arquivo.

Qual é a abordagem correta para resolver esses problemas?

1. mudança chmod
2. Altere o proprietário dos arquivos para coincidir com os do servidor da web e talvez defina o editor de texto (e o Finder?) Para ignorar a solicitação de senha ou usá-los sudo
3. Mude o proprietário do servidor da web para corresponder ao usuário do sistema operacional (não sei as consequências)
4. Algo mais

Apenas para declarar o óbvio para qualquer pessoa que esteja visualizando esta discussão .... se você der permissões a qualquer uma das suas pastas 777, estará permitindo que ALGUÉM leia, escreva e execute qualquer arquivo nesse diretório .... o que isso significa é que você forneceu QUALQUER PESSOA (qualquer hacker ou pessoa mal-intencionada em todo o mundo) permissão para fazer upload de QUALQUER arquivo, vírus ou qualquer outro arquivo e, em seguida, executar esse arquivo ...

Se você está definindo suas permissões de pasta para 777, você abriu seu servidor para qualquer pessoa que possa encontrar esse diretório. Claro o suficiente ??? :)

Existem basicamente duas maneiras de configurar sua propriedade e permissões. Você se torna proprietário ou torna o servidor da web o proprietário de todos os arquivos.

Servidor Web como proprietário (da maneira que a maioria das pessoas faz e da maneira do documento do Laravel):

assumindo que www-data (poderia ser outra coisa) é o usuário do servidor da web.

sudo chown -R www-data: www-data / caminho / para / seu / laravel / root / diretório

se você fizer isso, o servidor da web possui todos os arquivos, e também é o grupo, e você terá alguns problemas ao fazer o upload de arquivos ou ao trabalhar com arquivos via FTP, porque o seu cliente FTP efetuará login como você, não como seu servidor da Web. seu usuário ao grupo de usuários do servidor da web:

sudo usermod -a -G www-data ubuntu

Obviamente, isso pressupõe que seu servidor da web esteja sendo executado como www-data (o padrão Homestead) e seu usuário é ubuntu (é vago se você estiver usando o Homestead).

Em seguida, você define todos os seus diretórios para 755 e seus arquivos para 644 ... SET permissões de arquivo

sudo encontre / caminho / para / seu / laravel / root / diretório -type f -exec chmod 644 {} \;    

Permissões do diretório SET

sudo encontre / caminho / para / seu / laravel / root / diretório - tipo d -exec chmod 755 {} \;

Seu usuário como proprietário

Prefiro possuir todos os diretórios e arquivos (isso facilita muito o trabalho), então faço:

sudo chown -R meu usuário: www-data / caminho / para / seu / laravel / root / diretório

Então, eu concedo a mim e ao servidor da web permissões:

sudo encontre / caminho / para / seu / laravel / root / diretório -type f -exec chmod 664 {} \;    
sudo encontre / caminho / para / seu / laravel / root / diretório -type d -exec chmod 775 {} \;

Em seguida, conceda ao servidor da web o direito de ler e gravar no armazenamento e no cache

Qualquer que seja a forma de configuração, você precisa conceder permissões de leitura e gravação ao servidor da Web para armazenamento, cache e quaisquer outros diretórios que o servidor da Web precise carregar ou gravar também (dependendo da sua situação); portanto, execute os comandos do bashy acima:

bootstrap / cache de armazenamento de dados www sudo chgrp -R www
bootstrap / cache de armazenamento sudo chmod -R ug + rwx

Agora, você está seguro e seu site funciona, E você pode trabalhar com os arquivos com bastante facilidade

As permissões para as pastas storagee vendordevem permanecer em 775, por razões óbvias de segurança.

No entanto, tanto o seu computador quanto o servidor Apache precisam ser capazes de escrever nessas pastas. Ex: quando você executa comandos como php artisan, seu computador precisa gravar no arquivo de logs storage.

Tudo que você precisa fazer é atribuir a propriedade das pastas ao Apache:

sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage

Então você precisa adicionar seu computador (referenciado por ele username) ao grupo ao qual o servidor Apache pertence. Igual a :

sudo usermod -a -G www-data userName

NOTA: Na maioria das vezes, groupNameé www-datamas no seu caso, substitua-o_www

Nós encontramos muitos casos extremos ao configurar permissões para aplicativos Laravel. Criamos uma conta de usuário separada ( deploy) para possuir a pasta do aplicativo Laravel e executar comandos do Laravel a partir da CLI, e executamos o servidor web em www-data. Um problema que isso causa é que o (s) arquivo (s) de log podem pertencer a, www-dataou deploy, dependendo de quem escreveu o arquivo de log primeiro, obviamente impedindo que o outro usuário o grave no futuro.

Descobri que a única solução sã e segura é usar ACLs do Linux. O objetivo desta solução é:

1. Para permitir que o usuário dono / implante o aplicativo leia e grave o acesso ao código do aplicativo Laravel (usamos um usuário chamado deploy).
2. Permitir ao www-datausuário acesso de leitura ao código do aplicativo Laravel, mas não acesso de gravação.
3. Para impedir que outros usuários acessem o código / dados do aplicativo Laravel.
4. Para permitir que tanto o www-datausuário eo usuário do aplicativo ( deploy) acesso de gravação para a pasta de armazenamento, independentemente de qual usuário possui o arquivo (assim tanto deploye www-datapode escrever para o mesmo arquivo de log, por exemplo).

Realizamos isso da seguinte maneira:

1. Todos os arquivos na application/pasta são criados com o umask padrão 0022, o que resulta em pastas com drwxr-xr-xpermissões e arquivos -rw-r--r--.
2. sudo chown -R deploy:deploy application/(ou simplesmente implante seu aplicativo como deployusuário, e é isso que fazemos).
3. chgrp www-data application/para dar ao www-datagrupo acesso ao aplicativo.
4. chmod 750 application/para permitir a deployleitura / gravação do www-datausuário, somente leitura e remover todas as permissões para outros usuários.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/para definir as permissões padrão na storage/pasta e em todas as subpastas. Quaisquer novas pastas / arquivos criados na pasta de armazenamento herdarão essas permissões ( rwxpara ambos www-datae deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ para definir as permissões acima em qualquer arquivo / pasta existente.

Altere as permissões da pasta do projeto para ativar a leitura / gravação / exec para qualquer usuário dentro do grupo que possui o diretório (que no seu caso é _www):

chmod -R 775 /path/to/your/project

Em seguida, adicione seu nome de usuário do OS X ao _wwwgrupo para permitir que ele acesse o diretório:

sudo dseditgroup -o edit -a yourusername -t user _www

Como já publicado

Tudo que você precisa fazer é atribuir a propriedade das pastas ao Apache:

mas eu adicionei -R para o comando chown : sudo chown -R www-data:www-data /path/to/your/project/vendor sudo chown -R www-data:www-data /path/to/your/project/storage

A maioria das pastas deve ser "755" normal e arquivos, "644"

O Laravel exige que algumas pastas sejam graváveis ​​para o usuário do servidor web. Você pode usar este comando em sistemas operacionais baseados em unix.

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

Adicionar a compositer.json

"scripts": {
    "post-install-cmd": [
      "chgrp -R www-data storage bootstrap/cache",
      "chmod -R ug+rwx storage bootstrap/cache"
    ]
}

Depois de composer install

Os documentos do Laravel 5.4 dizem:

Depois de instalar o Laravel, você pode precisar configurar algumas permissões. Os diretórios nos diretórios storagee nos bootstrap/cachediretórios devem ser graváveis ​​pelo servidor da Web ou o Laravel não será executado. Se você estiver usando a máquina virtual Homestead, essas permissões já deverão estar definidas.

Há muitas respostas nesta página que mencionam o uso de 777permissões. Não faça isso. Você estaria se expondo a hackers.

Em vez disso, siga as sugestões de outras pessoas sobre como definir permissões 755 (ou mais restritivas). Pode ser necessário descobrir qual usuário seu aplicativo está executando executando whoamino terminal e depois alterar a propriedade de determinados diretórios usando chown -R.

Se você não tem permissão para usar, sudocomo muitas outras respostas exigem ...

Seu servidor provavelmente é um host compartilhado, como o Cloudways.

(No meu caso, eu havia clonado meu aplicativo Laravel em um segundo servidor Cloudways meu e não estava funcionando completamente porque as permissões dos diretórios storagee bootstrap/cacheestavam danificadas.)

Eu precisava usar:

Cloudways Platform > Server > Application Settings > Reset Permission

Então eu poderia correr php artisan cache:clearno terminal.

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

Isso funcionou para mim:

cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/

O que faz:

• Altere todas as permissões de arquivo para 644
• Altere todas as permissões de pasta para 755
• Para armazenamento e cache de autoinicialização (pastas especiais usadas pelo laravel para criar e executar arquivos, não disponíveis externamente), configure a permissão para 777, para qualquer coisa dentro

Nota: Talvez você não possa, ou não precise, fazê-lo com o prefixo sudo. depende das permissões do seu usuário, grupo, etc ...

Decidi escrever meu próprio roteiro para aliviar um pouco a dor da criação de projetos.

Execute o seguinte na raiz do projeto:

wget -qO- https://raw.githubusercontent.com/defaye/bootstrap-laravel/master/bootstrap.sh | sh

Aguarde o bootstrapping para concluir e você está pronto para ir.

Revise o script antes de usar.

Instalei o laravel na instância do EC2 e passei 3 dias para corrigir o erro de permissão e, finalmente, corrigi-lo. Então, eu quero compartilhar essa experiência com outra.

1. problema do usuário Quando efetuei login na instância ec2, meu nome de usuário é ec2-user e usergroup é ec2-user. E o site funciona sob o usuário httpd: apache: apache, portanto devemos definir a permissão para o apache.

2. permissão de pasta e arquivo A. estrutura da pasta primeiro, verifique se você possui essa estrutura de pastas como esta em armazenamento

   armazenamento

   • estrutura
     • cache
     • sessões
     • Visualizações
   • logs A estrutura da pasta pode ser diferente de acordo com a versão do laravel usada. minha versão do laravel é 5.2 e você pode encontrar a estrutura apropriada de acordo com a sua versão.

B. Permissão No início, vejo as instruções para definir 777 sob armazenamento para remover file_put_contents: falha ao abrir erro de fluxo. Então eu configurei a permissão 777 para armazenamento chmod -R 777 storage Mas o erro não foi corrigido. aqui, você deve considerar um: quem grava arquivos em armazenamento / sessões e visualizações. Isso não é ec2-user, mas apache. Sim certo. O usuário "apache" grava o arquivo (arquivo de sessão, arquivo de exibição compilado) na pasta de sessão e exibição. Portanto, você deve dar ao apache permissão de gravação para essa pasta. Por padrão: o SELinux diz que a pasta / var / www deve ser somente leitura pelo apache deamon.

Portanto, para isso, podemos definir o selinux como 0: setenforce 0

Isso pode resolver o problema temporariamente, mas isso faz o mysql não funcionar. então essa não é uma solução tão boa.

Você pode definir um contexto de leitura e gravação para a pasta de armazenamento com: (lembre-se de definir o force 1 para testá-lo)

chcon -Rt httpd_sys_content_rw_t storage/

Então seu problema será corrigido.

3. e não se esqueça desta atualização do compositor php artisan cache: clear

   Esses comandos serão úteis antes ou depois.

   Espero que você economize seu tempo. Boa sorte. Hacken

Eu tinha a seguinte configuração:

• NGINX (executando usuário: nginx)
• PHP-FPM

E aplicou as permissões corretamente, como @bgies sugerido na resposta aceita. O problema no meu caso foi o usuário e grupo em execução do php-fpm, que era originalmente apache.

Se você estiver usando NGINX com php-fpm, deverá abrir o arquivo de configuração do php-fpm:

nano /etc/php-fpm.d/www.config

E substitua usere groupo valor das opções por um NGINX está configurado para trabalhar; no meu caso, ambos foram nginx:

... ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. ; RPM: apache Choosed to be able to access some dir as httpd user = nginx ; RPM: Keep a group allowed to write in log dir. group = nginx ...

Salve-o e reinicie os serviços nginx e php-fpm.

Para desenvolvedores do Laravel, problemas de diretório podem ser um pouco problemáticos. No meu aplicativo, eu estava criando diretórios rapidamente e movendo arquivos para esse diretório no meu ambiente local com sucesso. Então, no servidor, eu estava recebendo erros ao mover arquivos para o diretório recém-criado.

Aqui estão as coisas que eu fiz e obtive um resultado bem-sucedido no final.

1. sudo find /path/to/your/laravel/root/directory -type f -exec chmod 664 {} \;
sudo find /path/to/your/laravel/root/directory -type d -exec chmod 775 {} \;
2. chcon -Rt httpd_sys_content_rw_t /path/to/my/file/upload/directory/in/laravel/project/
3. Ao criar o novo diretório rapidamente, usei o comando mkdir($save_path, 0755, true);

Depois de fazer essas alterações no servidor de produção, criei novos diretórios com sucesso e movi os arquivos para eles.

Por fim, se você usa a fachada File no Laravel, pode fazer algo assim: File::makeDirectory($save_path, 0755, true);

Encontrei uma solução ainda melhor para isso. É causado porque o php está sendo executado como outro usuário por padrão.

Então, para corrigir isso, faça

sudo nano /etc/php/7.0/fpm/pool.d/www.conf

depois edite o user = "put user that owns the directories" group = "put user that owns the directories"

então:

sudo systemctl reload php7.0-fpm