Início / server / Perguntas / 6895
Accepted
Gareth
Asked: 2009-05-11 21:13:03 +0800 CST

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

  • 772

Alguém tem uma boa solução 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, em vez de ter que ...

chown -R www-data:www-data

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

Pergunta complementar: Quão hardcore você vai em permissões?

Este sempre foi um problema em ambientes de desenvolvimento colaborativo.

linux debian apache-2.2 file-permissions www-data

4 respostas

  1. Best Answer

    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 ## grupos de exibição para 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=set group id, 7=rwx for owner (root), 7=rwx for group (www-pub), 5=rx for world (incluindo apache www-data user)

      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 o ID do usuário e STICKY (1) que eu acho que permite que apenas o proprietário exclua arquivos.

      Existe uma -Ropção recursiva, mas isso não discriminará entre arquivos e pastas, então você deve usar 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 padrão de criação de arquivos, 0002 significa que os arquivos terão 664 e os diretórios 775. Definir isso (editando a umasklinha na parte inferior /etc/profileno meu caso) significa que os arquivos criados por um usuário serão graváveis ​​por outros usuários no www- grupo sem precisar chmoddeles.

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

    Observação: você precisará sair/entrar para que as alterações em seus grupos entrem em vigor!

    • 220

  2. Não tenho certeza de como você deseja configurar as permissões, mas isso pode ser um ponto de partida. Provavelmente existem maneiras melhores. Estou assumindo que você deseja que ambos os 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
    • Altere todos os arquivos para 0664.
    • Altere o umask para seus usuários para 0002

    Isso significa que qualquer novo arquivo criado por qualquer um de seus usuários deve ser username:www-pub 0664 e qualquer diretório criado será username:www-pub 2775. O Apache terá acesso de leitura a tudo através do componente 'outros usuários'. O bit SETGID nos diretórios forçará todos os arquivos sendo criados a pertencerem 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 ao quão hardcore eu vou em permissões. Depende completamente do site/servidor. Se houver apenas 1-2 editores e eu só precisar evitar que eles quebrem muito as coisas, eu vou com calma. Se o negócio exigisse algo mais complexo, eu montaria algo mais complexo.

    • 62

  3. Eu acho que você pode achar o POSIX ACL (listas de controle de acesso) útil. Eles permitem um modelo de permissão mais refinado em comparação com o modelo user:group:other. Descobri que eles são mais fáceis de manter na minha cabeça, pois posso ser mais explícito e também definir o comportamento "padrão" para uma ramificação do sistema de arquivos.

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

    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 homem:

    Tutorial

    • 39

  4. Essa pergunta foi feita novamente e, conforme discutido no meta, as práticas recomendadas atuais fornecem abordagens melhores do que as disponíveis em 2009, quando isso foi feito. Esta resposta tenta dar algumas soluções atuais para lidar com ambientes de desenvolvimento web colaborativos de forma segura .

    Para um servidor web seguro e desenvolvimento colaborativo, há mais do que apenas as permissões de arquivo:

    • Tenha um usuário separado para cada site , ou seja, não veicule todos os sites usando www-data. Isso é importante, pois hoje em dia o Apache raramente está servindo apenas arquivos de conteúdo estáticos , mas executando sites dinâmicos . Esta resposta se concentra no PHP, pois é a linguagem de site de servidor mais comum , mas os mesmos princípios se aplicam às outras 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 com o mesmo usuário. Um invasor pode ver tudo o que o usuário vê, incluindo informações de login do banco de dados, e modificar todos os sites nos quais o usuário tem permissões de gravação.

    • Use o protocolo de transferência de arquivos SSH (SFTP). Embora o uso de FTP deva ser abandonado por segurança (já que envia as senhas e o conteúdo em texto simples), seu substituto seguro SFTP também possui um recurso que é uma solução perfeita para o desenvolvimento colaborativo da Web.

      Depois de ter isolado os sites e um usuário por site, você precisa dar acesso aos seus desenvolvedores da web, sobre o que é essa pergunta. Em vez de fornecer as senhas para esses usuários do site – ou acessar os arquivos do site usando suas contas de usuário pessoais como sugerido originalmente – você pode usar chaves SSH para login.

      Cada 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 as senhas e logins:

      • Cada desenvolvedor pode ter acesso a qualquer número de sites sem o ônus de lembrar ou armazenar todas as senhas envolvidas com o arranjo 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 desabilitar 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 para cada site. Isso é o melhor para segurança e desempenho, pois você também pode especificar quantos recursos um único site pode consumir.

      Veja, por exemplo, Run php-fpm do NeverEndingSecurity com usuário/uid e grupo separados no linux . Existem tutoriais como o do HowtoForge Using PHP-FPM with Apache on Ubuntu 16.04 que não usa PHP-FPM para aumentar a segurança por meio da separação de usuários, orientando a usar um único soquete FPM no servidor.

    • 13

relate perguntas