Implantando conteúdo no servidor web com rsync: permissões

Question

Eu tenho um servidor Ubuntu 10.04 rodando nginx com o nginx rodando como usuário nginx . Estou tentando implantar um site baseado em Octopress com o rsync e descobri o que parece ser um dilema de segurança.

Obviamente, todo o diretório /srv/www/ deve ser legível pelo usuário nginx , e alguns diretórios de upload devem ser graváveis pelo usuário nginx .

Octopress gosta de se conectar a um servidor via ssh, o que é bom. Como tenho um sentimento negativo sobre a concessão de nginx acesso remoto ao shell, criei um usuário especial ( deployer ) apenas para essa finalidade, que está configurado para ter acesso ao shell e pode se conectar via ssh. O Rsync funciona bem, mas todos os arquivos da web são copiados como pertencentes a deployer , e o usuário nginx não pode lê-los.

Eu poderia adicionar o usuário nginx ao grupo deployer e jogar com as opções --chmod e -p do rsync para permitir que o nginx / php grave nos diretórios de upload, mas não tenho certeza se ele não vai me morder mais tarde. Idealmente, acho que preciso de um tipo de rsync-then-chown e chmod, mas suspeito que seja um pouco demais para perguntar.

Quais são as melhores práticas? Como você faz isso?

Obrigado antecipadamente.

    

Answer 1

Este é um problema básico de acesso. Você quer ter dois usuários com acesso limitado e deseja que eles compartilhem arquivos de alguma forma.

A solução "tradicional" é criar um novo grupo, colocar os usuários lá e forçar de alguma forma que os arquivos sejam de propriedade desse grupo. Ainda assim, você terá problemas com o acesso de gravação se não definir as permissões corretamente e com os arquivos recém-criados. Ambos são solucionáveis (diretórios umask e setuid).

A melhor maneira que você não deve mordê-lo depois é cavar um pouco na estrutura, ver quais diretórios precisam ser graváveis por quem e modificar o cenário. Ou seja se você tem cache dir onde o usuário nginx precisa escrever - não sincronize via rsync e configure as permissões para que o nginx possa escrever lá.

O último recurso seria o script raiz (provavelmente do cron ou icron) para "corrigir" as permissões.