Como o ACL calcula as permissões efetivas em um arquivo?

Question

Eu executei o comando a seguir para fornecer as permissões wheel group rwx em novos arquivos e subdiretórios criados:

[belmin@server1]$ ls -la
total 24
drwxr-sr-x+   2 guards guards  4096 Aug 27 15:30 .
drwxr-xr-x  104 root   root   12288 Aug 27 15:19 ..

[belmin@server1]$ sudo setfacl -m d:g:wheel:rwX .

[belmin@server1]$ getfacl .
# file: .
# owner: guards
# group: guards
# flags: -s-
user::rwx
group::r-x
group:wheel:rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:wheel:rwx
default:mask::rwx
default:other::r-x

No entanto, quando eu crio um arquivo como root, não estou completamente claro como as permissões effective são calculadas:

[belmin@server1]$ sudo touch foo

[belmin@server1]$ getfacl foo
# file: foo
# owner: root
# group: guards
user::rw-
group::r-x                      #effective:r--
group:wheel:rwx                 #effective:rw-
group:guards:rwx                #effective:rw-
mask::rw-
other::r--

Alguém pode elaborar o que isso significa?

    

Answer 1

As permissões

effective são formadas por AND das permissões reais (real?) com o mask . Como o mask do seu arquivo é rw- , todas as permissões effective têm o x desativado.

    

Answer 2

Resposta curta: Se você quiser mascarar a máscara com o bit de execução, você deverá defini-la explicitamente usando setfacl após touch . A segurança proíbe sua configuração implícita.

setfacl -n -m m::rwx foo

"- n" para suprimir o recálculo da máscara (pode não ser necessário).
  "m :: rwx" define o valor da máscara para 'rwx'. Note que "m :: x" desabilitaria todas as leituras e gravações.

Não consigo mostrar por que a máscara é "rw-". Suponho que o diretório padrão em que touch cria o arquivo permanece inalterado para o exemplo inteiro do OP.

1. A entrada de diretório para 'foo' deve mostrar o proprietário 'root' (por causa do comando sudo e grupo 'guards' porque o diretório tem o bit SUID definido. As permissões serão padrões '-rw- .. .r-- 'com as permissões de grupo do diretório' -... rx ... '(devido aos bitins SUID tão pequenos).

2. Em seguida, vêm as ACLes, que devem ser o padrão do diretório. Dado que as ACLs herdam, eu não esperaria que nenhuma ACLe fosse criada, e a máscara ACLE fosse o diretório default, 'rwx'.

Mas se eles forem criados, eu esperaria que o novo ACLe seja iniciado a partir do padrão, novamente deixando a máscara em 'rwx'. Se eles não forem preparados a partir dos padrões, isso pareceria frustrar a ideia de uma ACL padrão - a ACL "padrão" forneceria apenas ACLs de usuário nomeado e grupo nomeado.

Isso agora levanta a questão de qual deve ser a máscara ACLe. Eu esperaria que fosse 'rwx' da entrada de máscara padrão. Mas poderia ser criado com uma máscara em branco, e então todos os tipos de legalistas se aplicam.

3. Com uma tentativa de ACL de usuário :: rw-, grupo :: rx, outro :: r--, grupo: roda: rwx, grupo: guardas: rwx e mascara ::: (não definido), consultamos o documentação para setfacl , assumindo que as mesmas regras se aplicam à criação de arquivos.

Existe uma cláusula:

If an ACL contains named user or named group entries, and no mask entry exists, a mask entry containing the same permissions as the group entry is created.

Isso definiria a máscara de ACL como "r-x", se a entrada do grupo de ACLs fosse criada a partir da entrada de diretório de arquivos, ou "r-x" se a entrada do grupo de ACL viesse da ACL padrão. (Maneira Ether, para este caso, o resultado é o mesmo.)

Existe também uma cláusula:

If a Default ACL contains named user entries or named group entries, and no mask entry exists, a mask entry containing the same permissions as the default Default ACL's group entry is added. ... the permissions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry.

Se esta regra se aplicar, a máscara iniciará como "rx" (mesma lógica) da cláusula anterior, e então será ajustada para ser a "união de todas as permissões afetadas pela entrada da máscara".

"permissões afetadas pela entrada de máscara" não estão definidas na documentação do comando setfacl . A documentação do POSIX ACL diz:

The mask is the combination of all access permissions of the owning group and all of the user and group entries.

Dê a palavra "união", que é aditiva, eu leria "combinação" para ser uma lógica ou. Em outras palavras, se algum grupo ou usuário ACLe tiver permissão "x", a máscara conterá "x".

4. Por toda essa lógica, o valor da máscara no exemplo do OP deve ser 'rwx', não importa qual caminho lógico foi seguido.

O raciocínio acima deve ser falho, pois o x para execução não aparece na máscara.

Portanto, deve haver alguma regra sobre como a máscara é calculada que foi "oculta" de fontes comuns de documentação (ou encontramos um bug).

Minha conclusão é que o 'x' está sendo removido incondicionalmente e a documentação é frouxa.

Essa mudança provavelmente foi feita com base na justificativa de "segurança" - nenhum arquivo deve ser implicitamente executável, mas deve ter o bit executável ativado após sua criação.