Quais relacionamentos vinculam a máscara da ACL e a permissão de grupo padrão em um arquivo?

No começo, crio um arquivo e verifico suas permissões padrão e entradas da ACL:

$ touch file; ls -l file; getfacl file
-rw-r--r-- 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
other::r--

Em seguida, defino a máscara da ACL no arquivo e verifique novamente suas permissões padrão e entradas da ACL:

$ setfacl -m mask:rwx file
$ ls -l file; getfacl file
-rw-rwxr--+ 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

Observe que, juntamente com a permissão de grupo padrão da máscara da ACL no arquivo, também foi alterado.

1. Que conexão existe entre a máscara ACL e a permissão de grupo padrão?
2. Qual é o motivo do acoplamento das permissões da máscara e do grupo de arquivos da ACL? Que lógica existe por trás disso?

As distribuições em questão são o Debian Linux 7.6 e o ​​CentOS 7

EDITAR

Neste ponto, eu só queria compartilhar algumas das minhas descobertas, enquanto pesquisava as relações entre as permissões padrão do grupo de arquivos e a máscara da ACL. Aqui estão as observações empíricas que encontrei:

1. A máscara da ACL pode ser alterada:

   1. configurando-o diretamente com o setfacl -m m:<perms>comando;
   2. alterando as permissões do grupo de arquivos com o chmodcomando (se a máscara da ACL já estiver presente; ela pode não estar presente porque é opcional se não houver permissões ACL de usuário ou grupo nomeadas no arquivo);
   3. adicionando a entrada ACL do usuário ou do grupo nomeado (a máscara será recalculada automaticamente).

2. A máscara aplicará direitos máximos de acesso (se houver entradas da ACL com permissões presentes que excedam as permissões da máscara da ACL) somente se a máscara for definida diretamente pelo setfacl ou pela modificação da permissão do grupo de arquivos com chmod (não calculado automaticamente). Quaisquer alterações nas entradas da ACL acionarão o recálculo automático da máscara da ACL e desativarão efetivamente o "modo de imposição".

3. Existem alguns efeitos colaterais que afetam implicitamente as permissões padrão do grupo de arquivos ao usar ACLs:

   1. A entrada ACL de usuário ou grupo nomeada aplicada a um arquivo pode alterar a máscara da ACL (aumentar suas permissões) e, portanto, as permissões efetivas do grupo de arquivos. Por exemplo, se você, como proprietário do arquivo, tiver permissões "rw-r - r-- jim students" definidas e também conceder permissão rw ao usuário "jack", também implicitamente concederá permissões rw a qualquer pessoa do grupo "alunos".
   2. A máscara da ACL mais rígida (menos permissões) pode remover permanentemente as permissões de grupo de arquivos padrão correspondentes. Por exemplo, se você tiver um arquivo com permissões padrão de grupo de arquivos rw e aplicar uma máscara ACL somente leitura ao arquivo, as permissões de grupo diminuirão para somente leitura. Se você remover todas as entradas estendidas da ACL (com setfacl -bcomando), as permissões do grupo permanecerão somente leitura. Isso se aplica apenas a máscaras de ACL mais rígidas, máscaras de ACL mais macias (mais permissões) não alteram permanentemente a permissão do grupo de arquivos original depois que ela é removida.

Não faz sentido se as permissões do arquivo unix discordam da entrada acl e vice-versa. Assim, a página do manual ( acl(5)) diz o que você pede:

CORRESPONDÊNCIA ENTRE AS INSCRIÇÕES DO ACL E OS BITS DE PERMISSÃO DE ARQUIVOS

As permissões definidas pelas ACLs são um superconjunto das permissões especificadas pelos bits de permissão do arquivo.

Há uma correspondência entre o proprietário do arquivo, o grupo e outras permissões e entradas específicas da ACL: as permissões do proprietário correspondem às permissões da entrada ACL_USER_OBJ. Se a ACL tiver uma entrada ACL_MASK, as permissões do grupo corresponderão às permissões da entrada ACL_MASK. Caso contrário, se a ACL não tiver nenhuma entrada ACL_MASK, as permissões do grupo corresponderão às permissões da entrada ACL_GROUP_OBJ. As outras permissões correspondem às permissões da entrada ACL_OTHER_OBJ.

O proprietário do arquivo, o grupo e outras permissões sempre correspondem às permissões da entrada ACL correspondente. A modificação dos bits de permissão do arquivo resulta na modificação das entradas da ACL associadas e a modificação dessas entradas na ACL resulta na modificação dos bits de permissão do arquivo.

Adendo em resposta à discussão:

Qual é o motivo do acoplamento das permissões da máscara e do grupo de arquivos da ACL? Que lógica existe por trás disso?

Uma boa explicação está aqui . Em essência, a máscara é uma

[...] limite superior das permissões que qualquer entrada na classe de grupo concederá.

Essa propriedade de limite superior garante que os aplicativos POSIX.1 que não têm conhecimento de ACLs não iniciem repentina e inesperadamente, concedendo permissões adicionais quando as ACLs forem suportadas.

Em ACLs mínimas, as permissões de classe de grupo são idênticas às permissões de grupo de propriedade. Nas ACLs estendidas, a classe de grupo pode conter entradas para usuários ou grupos adicionais. Isso resulta em um problema: algumas dessas entradas adicionais podem conter permissões que não estão contidas na entrada do grupo proprietário, portanto, as permissões de entrada do grupo proprietário podem diferir das permissões da classe do grupo.

Esse problema é resolvido pela virtude da entrada da máscara. Com ACLs mínimas, as permissões de classe de grupo são mapeadas para as permissões de entrada de grupo de propriedade. Com ACLs estendidas, as permissões da classe de grupo são mapeadas para as permissões de entrada da máscara, enquanto a entrada do grupo proprietário ainda define as permissões do grupo proprietário. O mapeamento das permissões de classe de grupo não é mais constante.

Finalmente entendi o que exatamente está ocorrendo quando vi este link Manipulando ACLs

Especificamente, essas máscaras basicamente substituem e funcionam para substituir NAMED USER e todas as permissões de GROUP. Isso significa se você:

1. ajuste a máscara, altere as permissões máximas do grupo,
2. se você alterar alguma das permissões de grupo com uma máscara presente, a máscara terá as permissões máximas de grupo de todas as permissões de grupo
3. As permissões de leitura, gravação e execução de grupo são determinadas com base na máscara, se houver

Espero que isso ajude.

Que lógica existe por trás disso?

A lógica é completamente quebrada e, portanto, as ACLs POSIX são um absurdo puro e inútil.

Se eles foram com o objetivo de preservar a compatibilidade com aplicativos que não têm noção de ACLs exceto padrão UNIX primitiva' modelo 'Ugo', eles realmente falhou no início, porque agora cada aplicativo que permissões limpa do grupo está efetivamente retirando o acesso adicionado por ACLs.