'setfacl' não se aplicam a diretórios criados pelo git clone?

Question

Veja como estou definindo permissões para o diretório-raiz do meu website, por exemplo, ~/public_html , onde os arquivos que meu site veicula são colocados:

sudo chgrp -R www-data ~/public_html
chmod g+s ~/public_html
chmod g+rwx ~/public_html
setfacl -m d:g:www-data:rwx ~/public_html

• O Comando # 1 dá acesso à propriedade de grupo "www-data" a ~/public_html ;
• # 2 define o ID do grupo, para que todos os novos diretórios / arquivos contidos nele também sejam de propriedade do grupo "www-data"
• # 3 define as permissões de acesso do grupo "www-data" no diretório para 775;
• # 4 garante que o mesmo se aplique a todos os novos diretórios / arquivos criados em ~/public_html .

Está funcionando muito bem, como deveria. Todos os novos diretórios e arquivos criados herdam as permissões forçadas.

O problema é com diretórios criados por git clone (depois que eu faço cd ~/public_html && git clone .... ).

ATUALIZADO: O diretório DOES herda o ID do grupo (isto é, "www-data" possui o diretório recém-criado), MAS NÃO o permissões de acesso (775 para diretórios e 664 para arquivos). Além disso, é apenas o diretório de nível superior que o git cria. Todos os diretórios e arquivos herdaram as permissões exatamente como deveriam. Pode ser que o pacote Debian git não tenha o conserto deste bug ainda?

O que estou fazendo de errado? Em vez disso, exatamente como eu deveria estar fazendo isso?

    

Answer 1

Provavelmente git sobrescreve o GID e as ACLs depois que os arquivos foram criados (como um simples mv faz ao mover um dispositivo cruzado). Você pode verificar isso executando-o através de strace ( strace -f -o git.strace -e trace=file ).

    

Answer 2

Se você estiver visualizando permissões diferentes usando git clone , é provável que seu umask esteja causando isso:

$ umask
0002

Os novos arquivos que estão sendo criados quando você executa o comando git clone estão sendo criados com permissões baseadas no que o umask especifica. Umask diz quais bits devem ser mascarados. Portanto, no exemplo acima, qualquer novo arquivo criado com umask de 0002 teria o outro bit de gravação desativado.

Referências

• O que é a Umask e como configurar umask padrão no Linux?
• o git clone produz permissões diferentes em servidores diferentes

Answer 3

É possível que git não consiga clonar os atributos estendidos do diretório public_html .

As ACLs (assim como os rótulos de arquivo do SELinux) no Linux são implementadas usando atributos estendidos baseados no sistema de arquivos (veja man pages para attr, getfattr, setfattr). Os atributos estendidos devem ser explicitamente copiados para que sejam preservados. A maioria dos utilitários de arquivos (mv, cp, tar, rsync, rm, e outros) na maioria das distros Linux modernas foram atualizadas para suportar atributos estendidos (e, por extensão, ACLs).

Refaça sua strace, mas não use a parte -e trace=file , canalize-a para grep xattr e veja se há alguma chamada para setxattr.

strace -f 2>&1 git clone | grep xattr

Se você não vir nenhuma saída, então git, ou pelo menos o que você está usando, não suporta atributos estendidos.