Qual é a melhor maneira de lidar com permissões para www-data do usuário do Apache 2 em / var / www?

Alguém tem uma boa solução para lidar com arquivos /var/www? Estamos executando hosts virtuais baseados em nome e o usuário do Apache 2 é www-data .

Temos dois usuários regulares e root. Então, ao mexer com arquivos /var/www, em vez de precisar ...

chown -R www-data:www-data

... o tempo todo, qual é uma boa maneira de lidar com isso?

Pergunta complementar: Qual é o grau de hardcore em que você passa as permissões?

Esse sempre foi um problema em ambientes de desenvolvimento colaborativo.

Tentando expandir a resposta de @ Zoredache , enquanto eu mesmo faço isso:

• Crie um novo grupo (www-pub) e adicione os usuários a esse grupo

  groupadd www-pub

  usermod -a -G www-pub usera ## deve usar -a para anexar a grupos existentes

  usermod -a -G www-pub userb

  groups usera ## exibir grupos para o usuário

• Altere a propriedade de tudo em / var / www para root: www-pub

  chown -R root:www-pub /var/www ## -R para recursivo

• Altere as permissões de todas as pastas para 2775

  chmod 2775 /var/www ## 2 = definir o ID do grupo, 7 = rwx para o proprietário (raiz), 7 = rwx para o grupo (www-pub), 5 = rx para o mundo (incluindo o apache www-data user)

  O bit Set ID do grupo ( SETGID ) (2) faz com que o grupo (www-pub) seja copiado para todos os novos arquivos / pastas criados nessa pasta. Outras opções são SETUID (4) para copiar a identificação do usuário e STICKY (1), que eu acho que permite apenas que o proprietário exclua arquivos.

  Há uma -Ropção recursiva, mas que não discrimina arquivos e pastas, então você deve usar o find , assim:

  find /var/www -type d -exec chmod 2775 {} +

• Altere todos os arquivos para 0664

  find /var/www -type f -exec chmod 0664 {} +

• Altere o umask para seus usuários para 0002

  O umask controla as permissões de criação de arquivo padrão, 0002 significa que os arquivos terão 664 e os diretórios 775. Definir isso (editando a umasklinha na parte inferior do /etc/profilemeu caso) significa que os arquivos criados por um usuário serão graváveis ​​por outros usuários no site www- grupo sem precisar chmoddeles.

Teste tudo isso criando um arquivo e um diretório e verificando o proprietário, o grupo e as permissões com ls -l.

Nota: Você precisará fazer logout / login para que as alterações nos seus grupos entrem em vigor!

Não sei ao certo como você deseja configurar as permissões, mas isso pode lhe dar um ponto de partida. Provavelmente existem maneiras melhores. Suponho que você deseja que os dois usuários possam alterar qualquer coisa em / var / www /

• Crie um novo grupo (www-pub) e adicione os usuários a esse grupo.
• Altere a propriedade de tudo em / var / www para root: www-pub.
• Altere as permissões de todas as pastas para 2775
• Mude todos os arquivos para 0664.
• Altere o umask para seus usuários para 0002

Isso significa que qualquer novo arquivo criado por um de seus usuários deve ser o nome de usuário: www-pub 0664 e qualquer diretório criado será o nome de usuário: www-pub 2775. O Apache terá acesso de leitura a tudo por meio do componente 'outros usuários'. O bit SETGID nos diretórios forçará todos os arquivos que estão sendo criados a pertencer ao grupo que possui a pasta. É necessário ajustar o umask para garantir que o bit de gravação esteja definido para que qualquer pessoa no grupo possa editar os arquivos.

Quanto à forma como eu explico as permissões. Depende completamente do site / servidor. Se houver apenas 1 a 2 editores e eu apenas precisar impedi-los de quebrar as coisas muito mal, eu irei fácil. Se o negócio exigisse algo mais complexo, eu configuraria algo mais complexo.

Eu acho que você pode achar que POSIX ACL (listas de controle de acesso) é útil. Eles permitem um modelo de permissão mais refinado em comparação com o usuário: grupo: outro modelo. Eu achei que eles são mais fáceis de manter em mente, pois posso ser mais explícito e também posso definir o comportamento "padrão" para uma ramificação do sistema de arquivos.

Por exemplo, você pode especificar explicitamente as permissões de cada usuário:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Ou você pode fazer isso com base em algum grupo compartilhado:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

E talvez você queira manter seu usuário Apache como somente leitura

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Páginas de manual:

• setfacl
• getfacl

Tutorial

Essa pergunta foi feita novamente e, conforme discutido na meta, as melhores práticas atuais oferecem melhores abordagens do que as disponíveis em 2009, quando isso foi feito. Esta resposta tenta fornecer algumas soluções atuais para lidar com ambientes de desenvolvimento colaborativo da Web com segurança .

Para um servidor Web seguro e desenvolvimento colaborativo, existem mais do que apenas as permissões de arquivo:

• Tenha um usuário separado para cada site, ou seja, não atenda a todos os sites usando www-data. Isso é importante, pois atualmente o Apache raramente atende apenas arquivos de conteúdo estático , mas executa sites dinâmicos . Essa resposta se concentra no PHP, pois é a linguagem mais comum do site do servidor, mas os mesmos princípios se aplicam aos outros também.

  Se você tiver um problema de segurança em um único site, ele poderá se espalhar para todos os sites em execução como o mesmo usuário. Um invasor pode ver tudo o que o usuário vê, incluindo informações de login no banco de dados, e modificar todos os sites aos quais o usuário tem permissão de gravação.

• Use o protocolo SFTP ( SSH File Transfer Protocol ). Embora o uso do FTP deva ser abandonado por segurança (como envia as senhas e o conteúdo em texto sem formatação), seu substituto seguro SFTP também possui um recurso que é uma solução perfeita para o desenvolvimento colaborativo da Web.

  Depois de isolar os sites e um usuário por site, você precisa dar acesso aos desenvolvedores da Web, sobre o que é essa questão. Em vez de fornecer a eles as senhas para esses usuários do site - ou acessar os arquivos do site usando suas contas de usuário pessoais, conforme sugerido originalmente -, você pode usar as chaves SSH para fazer login.

  Todo desenvolvedor pode gerar um par de chaves e manter a chave privada em segredo. Em seguida, a chave pública é adicionada ao ~/.ssh/authorized_keysarquivo para cada conta de usuário do site em que o desenvolvedor está trabalhando. Isso tem muitas vantagens para gerenciar senhas e logins:

  • Todo desenvolvedor pode ter acesso a qualquer número de sites da Web, sem o ônus de lembrar ou armazenar todas as senhas envolvidas na organização do usuário por site.

  • Não há necessidade de alterar e compartilhar as senhas toda vez que alguém sai da empresa.

  • Você pode usar senhas muito fortes ou desativar completamente o login baseado em senha.

• Use PHP-FPM . É a abordagem atual para executar o PHP como usuário. Crie um novo pool para cada usuário, ou seja, um pool por cada site. É o melhor para segurança e desempenho, pois você também pode especificar a quantidade de recursos que um único site pode consumir.

  Veja, por exemplo, execute o php-fpm de NeverEndingSecurity com user / uid e grupo separados no linux . Há tutoriais como de HowtoForge Utilizando PHP-FPM com Apache no Ubuntu 16.04 que não usa PHP-FPM para aumentar a segurança através da separação do usuário, orientando a utilização de um único soquete FPM em todo o servidor.