Como habilitar scripts CGI compatíveis com o suexec que podem ser gravados em grupo?

Question

Fui solicitado a configurar um espaço da Web compartilhado em nosso servidor de departamento que pode ser acessado por várias pessoas e que pode estar executando scripts CGI ou PHP. As pessoas que mantêm o espaço na Web podem decidir usá-lo para envios de arquivos, o que significaria que precisariam acessar todos os arquivos criados pelos scripts. Estamos executando o Apache no Scientific Linux 6.

Como várias pessoas precisam de acesso de gravação ao espaço da Web, nossa abordagem padrão é criar um grupo ao qual todas as pessoas relevantes pertençam e, em seguida, definir as permissões nos diretórios no espaço da Web como g+ws . O suexec está insatisfeito com os arquivos sendo graváveis por grupo e se recusa a executá-los.

Como podemos configurar isso e garantir que quaisquer scripts sejam executados em uma conta que seja diferente da conta principal do Apache (e seja diferente de qualquer um dos usuários que não são no grupo para o espaço web)? Por razões de responsabilidade (e outras), prefiro não ter que criar uma conta compartilhada que as várias pessoas precisariam usar para manter esse espaço na Web.

Para um pouco mais de contexto, veja como estamos atualmente configurados: temos usuários cujos diretórios pessoais estão no NFS e montados automaticamente conforme necessário. A maioria das pessoas usa apenas o seu espaço pessoal acessado via mod_userdir. Colocamos em campo vários pedidos de espaço da Web compartilhado no passado, criando diretórios montados automaticamente no servidor NFS que não estão vinculados a contas específicas, mas que possuem propriedade de grupo configurada para facilitar o acesso de várias contas. Até agora, esses espaços compartilhados continham apenas conteúdo estático (e confiamos nas pessoas envolvidas para não executar scripts a partir deles), portanto, nunca tivemos que abordar nenhum problema relacionado ao suexec para esses tipos de espaços antes.

Editar : observe que os usuários podem precisar acessar os arquivos criados pelos scripts.

    

Answer 1

Para garantir a responsabilidade nesse contexto e ainda fornecer a propriedade e as permissões corretas para o conteúdo publicado, eu uso uma versão ligeiramente modificada do fluxo de trabalho descrito em este artigo.

Isto é como eu implementei, note que a maioria das peças são substituíveis:

• Todo o conteúdo publicado é gerenciado por um sistema de controle de versão (git neste caso)
• Os usuários têm contas nominais registradas em um LDAP Kerberizado, juntamente com suas chaves públicas RSA
• No passado, eu usava essas chaves públicas para conceder acesso aos repositórios diferentes usando gitosis / gitolite, mas você também pode usar o git simples com o git-shell.
• Um tempo atrás, mudei para gitblit, que fornece autorização LDAP. O acesso à UI da web do gitblit requer um ticket kerberos válido.
• Os repositórios têm o gancho pós-atualização vinculado a um script que contém:

#!/bin/sh

sudo /usr/local/sbin/publisher-hub2live

exit 0

O script não está acessível diretamente a usuários não autorizados:

# ls -lrt /usr/local/sbin/publisher-hub2live
-rwx------. 1 root root 400 Oct 12  2012 /usr/local/sbin/publisher-hub2live

Daí o sudorule:

Defaults:git   !requiretty
git   Host_Alias = (root) NOPASSWD: /usr/local/sbin/publisher-hub2live

Substitua git pelo proprietário atual dos repositórios.

O conteúdo do script do editor trabalha a "mágica" aqui (versão simplificada):

#!/bin/sh

echo
echo "**** Pulling changes into Live [Hub's post-update hook]"
echo

cd /path/to/live/repo || exit
umask 0022
unset GIT_DIR
git pull hub master

chown -R root:root /path/to/live/repo
find /path/to/live/repo/ -type d | xargs chmod u=rwx,go+rx
find /path/to/live/repo/ -type f | xargs chmod u=rw,go+r
restorecon -v -R /path/to/live/repo

exec git update-server-info

exit 0

Suas necessidades podem ser diferentes em relação às permissões de proprietário, grupo, DAC e MAC, mas o fluxo de trabalho é o mesmo.