Eu tenho um diretório que pode ser lido e escrito por um par de grupos unix. Isso é conseguido usando ACLs. Vamos supor que eu fiz assim:
mkdir /tmp/test
setfacl -d -m g:group1:rwx /tmp/test
Funciona muito bem, todo o grupo (E outros grupos que eu adiciono assim) pode ler / escrever neste diretório. MAS há uma exceção: quando alguém cria uma subpasta usando mkdir -p , esse diretório é criado com as permissões unix 0755, porque o umask padrão é 022. Isso resulta no problema que outros usuários do grupo não podem mais gravar nesse arquivo. subpasta porque a ACL agora se parece com isso:
group:group1:rwx #effective:r-x
Por alguma razão, isso não acontece ao usar "mkdir" (Sem argumento -p). Uma solução é configurar o umask para 002, mas isso é realmente uma coisa ruim, porque isso também afeta arquivos e diretórios criados fora dos diretórios controlados por ACL e esses arquivos não devem ser graváveis em grupo por padrão.
Então, pergunto-me se há outra possibilidade para resolver este problema. Seria perfeito ser capaz de desabilitar / ignorar completamente o antigo material de permissão do estilo unix para um diretório controlado por ACL. Ou desative este material "ACL efetivo". Isso é possível? Ou existe outra maneira de resolver o problema com diretórios não graváveis causados por programas como "mkdir -p"? No final, eu quero um diretório que seja completamente (e recursivamente) legível e gravável de acordo com as ACLs que eu configurei e isso nunca deve mudar (somente modificando as próprias ACLs).
Nota: para reproduzir o problema:
$ mkdir /tmp/test
$ setfacl -d -m g:group1:rwx /tmp/test
$ umask 0022
$ mkdir /tmp/test/aa
$ mkdir -p /tmp/test/bb
$ ls -log /tmp/test
drwxrwxr-x+ 2 4096 Mar 9 23:38 aa
drwxr-xr-x+ 2 4096 Mar 9 23:38 bb
$ getfacl /tmp/test/bb | grep ^group:group1
group:group1:rwx #effective:r-x
É um bug com o gnu mkdir : link Não há como desativar as permissões tradicionais do Unix. Como mkdir funciona, você pode escrever uma função de shell que substitui mkdir . Na função shell, procure por -p nos argumentos e execute uma série de não-p usando mkdir s.
Muitos sistemas baseados em Linux agora usam umask 0002 com grupos de usuários particulares, então esse problema não aparece.
Foi um bug com o gnu mkdir ( # 14371 ), foi corrigido em coreutils 8.22.
Existem algumas soluções alternativas.
Solução nº 1: wrapper (já sugerido por Mark Wagner)
Como o mkdir funciona, você pode escrever uma função de shell que substitui o mkdir (ou um script / usr / local / bin / mkdir, pois isso é normalmente feito antes / bin). Esse script procura por um -p nos args então invoca recursivamente o mkdir sem "-p".
Solução nº 2: umask 0002
Se você pode controlar o script que chama mkdir, você pode definir a máscara antes de chamar mkdir:
(umask 0002 ; mkdir -p /path/to/dir)
Suas outras perguntas:
So I wonder if there is another possibility to solve this problem. It would be perfect to be able to completely disable/ignore the old unix-style permission stuff for a ACL-controlled directory.
Não, a permissão é necessária para compatibilidade, leia também Por que o chmod (1) no grupo afeta a máscara da ACL?
Or disable this "effective ACL" stuff.
Não
Você tentou definir o bit setgid no diretório que contém? Isso deve impor as mesmas permissões em todos os novos arquivos e diretórios contidos nele.