Permissões de usuário para o apache e o usuário local

Question

Estou tentando permitir permissões para arquivos na pasta / home / user1 / public_html / para user1 e www-data (apache).

Recebi instruções para executar estes comandos:

sudo chown -R www-data:user1 /home/user1/public_html/
sudo chmod g+s /home/user1/public_html/

Agora, o www-data tem acesso para editar / remover / adicionar arquivos a / home / user1 / public_html /, mas o usuário1 não pode editar nada.

Como posso resolver isso?

Obrigado,

    

Answer 1

A melhor maneira de conseguir isso é com ACLs posix . Permissões padrão de arquivos unix não são suficientes. Você pode fazer isso com alguns kludging, mas não é muito mais do que um kludge, basicamente não é uma solução simples.

O uso de uma ACL resolverá esse problema de forma sucinta. Para fazer isso, você pode usar os seguintes comandos:

setfacl -R -m www-user:rwx /home/user1/public_html
setfacl -R -d -m www-user:rwx /home/user1/public_html
setfacl -R -m user1:rwx /home/user1/public_html
setfacl -R -d -m user1:rwx /home/user1/public_html

O sinalizador -d faz com que os novos arquivos herdem as ACLs que você definiu no diretório.

Há algumas advertências a serem lembradas.

1. Seu sistema de arquivos deve suportá-lo (a maioria desses dias, eles podem ser ativados remontando o sistema de arquivos com suporte a ACL na maioria dos sistemas de arquivos). Coisas como o NFS não funcionam.
2. A ACL padrão do grupo Unix se torna uma máscara. I.E Se um arquivo diz g + x o arquivo é executável com o comando acima. se o seu arquivo não for executável, independentemente de o conjunto de permissões ser ou não rwx na ACL. Isso garante que você evite uma situação em que você teria que marcar todos os diretórios rwx no acl e em todos os arquivos rw - .

Isso corrige um problema de maneira sensata e permite várias combinações de cenários:

• Aplica o menor privilégio, pois você não precisa começar a modificar as associações de grupos de usuários.
• user1 pode criar um arquivo que pode ser modificado mais tarde por www1-user (assim o usuário1 pode fazer upload de conteúdo SFTP que pode ser excluído e / ou modificado por um CMS no apache posteriormente) e vice-versa.
• O Apache permanece em uma conta do sistema que evita ter que usar as soluções alternativas do SetUID para alterar o assunto do apache (usuário).
• A modificação se aplica somente a uma estrutura de diretórios específica e não permite inadvertidamente permitir acesso de usuário ou usuário1 a outras partes da árvore do sistema de arquivos que você não deseja que elas acessem.
• Alterar ou revogar permissões é uma alteração trivial.

Esta é a minha maneira preferida de resolver esse tipo de problema. É uma mudança simples, não disruptiva e trivial.

    

Answer 2

O Apache não precisa escrever em todos os lugares, para isso você pode especificar tmp, upload, etc. pastas. Então você pode definir permissões para public_dir para ser legível e executável pelo usuário do apache:

sudo chown user1:www-data /home/user1/public_html
sudo chmod 0750 /home/user1/public_html

Todos os outros arquivos em public_html dir podem estar sob permissões de usuário1 e somente legíveis por "outros" (apache aqui). Isso também é melhor do ponto de vista de segurança. Como escrevi, apenas arquivos / pastas necessários devem ser graváveis pelo usuário do apache.

    

Answer 3

A solução mais simples é garantir que o www-data possa navegar por todos os diretórios para o diretório / home / user1 / public_html e usar as permissões do diretório 755 de public_html e down. Arquivos no diretório public_html precisam ser mundiais (outros) legíveis. Estes comandos devem permitir o acesso:

sudo chmod o+x /home
sudo chmod 0+x /home/user1
find /home/user1/public_html -type d ! -perm -005 -print0 | xargs -0 sudo chmod o+rx
find /home/user1/public_html -type f ! -perm -004 -print0 | xargs -0 sudo chmod o+r

O primeiro comando provavelmente não é necessário. Alguns sistemas restringem o acesso aos diretórios home de maneira bastante severa, e isso é corrigido pelo segundo comando. Ele permite que os arquivos sejam abertos no diretório inicial, mas não concede a capacidade de listar o diretório.

Os últimos três comandos podem ser executados pelo usuário com sudo removido.

    

Answer 4

Se você fez:

sudo chown -R www-data:user1 /home/user1/public_html/

Você deu a propriedade ao usuário www-data e ao usuário do grupo1.

Com:

sudo chmod g+s /home/user1/public_html/

Você definiu o ID do grupo em execução nesta pasta, eu nunca vi isso feito antes e não tenho idéia de por que alguém faria isso ... Geralmente é usado em binários. Você está bagunçando as coisas com isso. A menos que você encontre uma razão válida para isso, inverta isso:

sudo chmod g-s /home/user1/public_html/

E defina permissões de leitura / gravação para o usuário1 (que pertence ao grupo user1) e www-data.

sudo chmod -R 770 /home/user1/public_html

E agora você tem cada arquivo gravável e legível por www-data e todos os usuários no grupo user1 (que eu assumo apenas o usuário1 é parte, verifique isso).

Isso está sujo, pois você pode querer que alguns arquivos sejam graváveis apenas pelo usuário. Como desenvolvedor, não é incomum "carregar" arquivos no servidor, em vez de apenas editá-los; isso resolve os problemas de gerenciamento certos, terceirizando-os para um programa seguro como sftp / scp. Você pode até tentar usar um SCM.

    

Answer 5

É mais provável que você tenha user1 e www-data no caminho errado nos comandos da pergunta.

Você não quer dar permissões de gravação do apache por padrão - e fazer com que o usuário do apache o proprietário faça exatamente isso.

Tente isto:

sudo chown -R user1:www-data /home/user1/public_html/
sudo find /home/user1/public_html/ -type d -exec chmod 0755 {} \; -or -type f -exec chmod 0644 {} \;

Isso fará com que você seja o proprietário e use o mesmo grupo que o apache. Em seguida, redefina as permissões para 755 para pastas e 644 para arquivos. as 7 5 5 e 6 4 4 permissões são as que se aplicam ao apache - apenas dê permissões de escrita do apache para as pastas nas quais ele precisa escrever.