Usando uma não raiz para implantar um repositório git na raiz da web

Question

Qual é a melhor maneira de configurar usuários e permissões para um servidor Web de produção que usa o git para implantar no servidor?

Plano de fundo

Rodando o Ubuntu 12.04, eu tenho arquivos de serviço do apache em /var/www as www-data . Eu também tinha um repositório nulo no diretório de usuários raiz que efetuaria o checkout para /var/www/example.com no gancho pós-recebimento.

Isso funcionou bem, mas considerando que é um servidor de produção, eu queria abotoar alguma segurança e remover o repositório do usuário root. Então criei um usuário git e configurei o repo em /home/git . Mas agora tenho problemas de permissões sobre o fato de um usuário possuir o repositório enquanto outro usuário possui a raiz da Web.

Li muitos fóruns e tutoriais on-line. A maioria parece apenas usar o usuário root, outros parecem ter problemas de segurança piores (como www-data permissões de leitura sobre o repositório). Estou procurando insights da experiência do mundo real porque há muitas maneiras de fazer isso.

Como nota, o gancho pós-recebimento faz mais do que a finalização da compra. Ele também executa alguns processos de construção, como a execução do Composer e alguns outros scripts php que podem levar vários minutos.

Eu tentei várias soluções:

Eu tentei adicionar o usuário git ao www-data group , depois chowning a raiz da web de volta para www-data no final do gancho. Isso tem dois problemas. Primeiro, eu tenho que modificar o arquivo sudoers, e os resultados que obtenho são erráticos. Em segundo lugar, durante esses vários minutos enquanto o gancho está em execução, os arquivos que sofreram check-out são de propriedade de git, não www-data , para que os usuários no site possam receber erros de leitura.

Eu tentei colocar o conteúdo do post-receive em outro arquivo e executá-lo com o sudo. Novamente, isso requer a edição dos arquivos sudoers, para que o usuário git possa sudo sem uma senha.

Ou pode ser que deixar o repositório sob o usuário root seja o mal menor e eu estou fazendo tudo isso por nada.

Existe uma solução melhor que eu não tentei?

    

Answer 1

Crie um novo grupo e adicione o usuário git e www-data a ele. Em seguida, configure seu repositório git bare para sempre usar o grupo que você criou como o gid para os arquivos do repositório. Com uma nova respiração nua você faz isso com esse git init --shared=group . ( Ref ) Isso permitirá que a conta www-data leia o repositório.

Atualize seus sudoers para permitir que a conta git execute comandos como www-data sem uma senha.

# file: /etc/sudoers.d/gitpush
# permissions should be 0440
# git user is allowed to basically do anything as the www-data user
git ALL=(www-data) NOPASSWD: ALL

Em seguida, basta ter seu post-receive script sudo -u www-data para todos os comandos necessários para executar as verificações / correções.

    

Answer 2

Acho que há uma maneira melhor de lidar com esse cenário.

Primeiro, eu mudaria de git simples para algo com algum tipo de controle de acesso baseado em função (RBAC), como gitolite .

Também recomendo ler este artigo descrevendo um fluxo de trabalho muito semelhante ao você precisa.

Para implementar uma solução para seus requisitos, as etapas seriam:

1. conceda o RBAC usando as chaves RSA usando gitolite
2. configure e use os ganchos descritos no artigo vinculado acima para garantir a exatidão em relação ao proprietário, ao grupo e às permissões.

As vantagens são muitas, na minha opinião:

1. você não precisa dar acesso direto aos arquivos para ninguém
2. você pode acionar qualquer coisa dos post-update scripts de gancho
3. toda interação com o conteúdo publicado ocorre por meio do repositório git , portanto, a auditoria se torna uma tarefa simples ( git log e git blame )
4. você não precisa jogar com ACLs ou com permissões de grupo de mistura (DAC)
5. você pode usar segurança de controle de acesso obrigatório (MAC) de forma transparente

Answer 3

Em um padrão mod_php /var/www/example.com poderia ser de propriedade de um usuário git, e quaisquer arquivos / pastas que precisassem ser graváveis por php, precisariam ser de propriedade de www-data (ou ter 666/777 permissões). Nesse caso, um virtualhost poderia gravar os outros arquivos do virtualhost.

ou: Se você estiver executando o mod_php, você pode adicionar, por exemplo, o mod_ruid2 ao Apache e, em seguida, executar cada virtualhost com seu próprio uid. Qual seria o usuário git neste caso. Ou php-fpm se você preferir fastcgi como setup e cada virtualhost ter seu próprio php-fpm pool. Dessa forma, cada virtualhost poderia gravar seus próprios arquivos, mas não arquivos de outros hosts virtuais.

Depende, como você preferir.