it-swarm-pt.tech

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 solução agradável para lidar com arquivos em /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 em /var/www, ao invés de ter que ...

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.

218
Gareth

Tentando expandir o @ Zoredache's resposta , 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 recursiva

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

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

    Definir ID do grupo ( SETGID ) bit (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á um -R opção recursiva, mas que não discrimina arquivos e pastas, então você precisa se 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. Configurando isso (editando a linha umask na parte inferior de /etc/profile no meu caso) significa que os arquivos criados por um usuário serão graváveis ​​por outros usuários no grupo www sem a necessidade de chmod.

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

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

209
Tom

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.

62
Zoredache

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:

Tutorial

39
Joe Holloway

Esta pergunta foi feita novamente , e como discutido na meta, as práticas recomendadas atuais fornecem melhores abordagens do que as disponíveis em 2009, quando isso foi feito. Esta resposta tenta fornecer algumas soluções atuais para manipular 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 está servindo apenas estático arquivos de conteúdo, mas executando - dinâmico sites. Esta resposta concentra-se em PHP como é a linguagem mais comum servidor-site), 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 SSH File Transfer Protocol (SFTP). Enquanto estiver usando o FTP, deve ser abandonado por segurança (pois envia ambos os 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 SSH keys 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_keys arquivo 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 PHP como usuário. Crie um novo pool para cada usuário, ou seja, um pool para 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.

    Ver p. NeverEndingSecurity Execute php-fpm com user/uid separado e grupo no linux . Existem tutoriais como o do HowtoForge sando o PHP-FPM com Apache no Ubuntu 16.04 que não usa o PHP-FPM para aumentar a segurança através da separação do usuário, orientando o uso de um único soquete FPM no servidor.

11
Esa Jokinen