Compartilhe diretórios com usuários do processo

Question

Suponha que eu tenha um diretório /clients/bob , que pertence a bob:bob

Eu posso conceder aos desenvolvedores o grupo bob para que eles possam editar esses arquivos e depois removê-los desse grupo quando eles não precisarem mais de acesso.

No entanto, o que eu faço para processar usuários como www-data ? Eu não quero colocar www-data no grupo bob porque isso daria ao Apache acesso a tudo e não apenas à raiz do documento do site. Da mesma forma, não quero dar a propriedade da raiz do documento para bob:www-data ou www-data:bob porque essa solução não é dimensionada quando preciso conceder dois usuários do processo acesso ao diretório (suponha que eu tenha um cronjob sendo executado em outro usuário )

    

Answer 1

Você deve considerar o usuário www-data como "todos" e conceder acesso de acordo.

Se você acha que o recurso da Web foi protegido corretamente, você também pode se afastar do sistema de permissão octal básico e usar as Listas de controle de acesso:

setfacl -R -m u:www-data:rX my-directory

Isso permite que www-data u ser acesse dados e insira diretórios, a partir de my-directory . ( -R é o mesmo que em chmod , significa aplicar a alteração recursivamente.)

Para que arquivos e pastas recém-adicionados também tenham essa ACL, você precisa definir a ACL padrão:

setfacl -R -d -m u:www-data:rX my-directory

Observe que as ACLs devem estar ativadas no kernel e no ponto de montagem. Consulte o manual do sistema de arquivos que você está usando para isso. Agora é o padrão na maioria das distribuições do Linux, por isso talvez já esteja disponível.

    

Answer 2

Acho que Listas de Controle de Acesso (da resposta de Daniel B) estão OK. Eles são poderosos com certeza. Caso você não possa usá-los, a seguinte solução menos poderosa pode ser suficiente:

1. Crie um grupo especialmente para este caso, por ex. cl_bob .
2. Em seguida, chown da raiz do documento (recursivamente) para bob:cl_bob .
3. Adicione usuários (incluindo usuários do processo) a cl_bob group. O usuário www-data deve estar em cl_bob , mas não em bob ; os desenvolvedores podem precisar estar em ambos.
4. Ative o setgid para os diretórios:
   find /clients/bob/document/root -type d -exec chmod g+s "{}" +
   Dessa forma, futuros diretórios e arquivos criados nele herdarão o grupo cl_bob , independentemente do usuário (processo) que os cria.
5. Outro usuário (como no seu exemplo do cronjob) pode ser facilmente adicionado ao grupo mais tarde.

Vantagens sobre o ACL:

• Muito simples e bem conhecido.
• Fácil de inspecionar com ferramentas padrão como ls -l .
• Amplamente suportado fora da caixa.
• Adicionar (remover) usuário ao grupo é uma operação simples que gera quase nenhuma E / S de disco nem leva tempo. O caso pode ser diferente ao aplicar recursivamente os metadados da ACL.

Desvantagens:

• Não é tão flexível. Usuário diferente de bob is xor não está em cl_bob , então as permissões de grupo xor outras permissões se aplicam, tertium non datur . Se você quiser mais níveis de permissão (por exemplo, leitura / gravação completa, somente leitura limitada, sem acesso), precisará da ACL.
• Todo o sistema. Você precisa de acesso root para criar um grupo e adicionar usuários a ele; informações cruciais são armazenadas em /etc/group . A ACL é muito mais "privada", como um nome de arquivo; Os metadados da ACL são armazenados no sistema de arquivos (mas você ainda precisa do /etc/group e /etc/passwd para conectar GIDs e UIDs ao mundo real).
• Pode gerar lixo. Imagine que você removeu /clients/bob de todo o conteúdo dentro dele; O grupo cl_bob agora é um artefato inútil, a menos que você lembre de excluí-lo também. Os metadados da ACL são removidos junto com os arquivos, não há mais lixo.