Por que o chmod (1) no grupo afeta a máscara da ACL?

Question

Estou tentando entender esse comportamento do Unix (que, por acaso, estou testando no Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Observe que o comando chmod (1) atualizou a máscara do ACL. Por que isso acontece?

A página do SunOS tem o seguinte para dizer:

If you use the chmod(1) command to change the file group owner permissions on a file with ACL entries, both the file group owner permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions may change the effective permissions for additional users and groups who have ACL entries on the file.

Eu pergunto porque seria conveniente para mim se chmod (1) não tivesse esse comportamento. Espero que, ao entender por que ele faz o que faz, eu possa projetar melhor como configuro as permissões do sistema de arquivos.

    

Answer 1

Não seria conveniente se você chmod() não tivesse esse comportamento.

Seria altamente inconveniente, porque as coisas que as pessoas tradicionalmente esperam que funcionem em Unixes quebrariam. Esse comportamento te serve bem, mas você sabe disso.

É uma pena que o IEEE 1003.1e nunca tenha se tornado um padrão e tenha sido retirado em 1998. Na prática, 14 anos depois, é um padrão que uma ampla gama de sistemas operacionais - de Linux através de FreeBSD para Solaris - realmente implementar.

O rascunho de trabalho # 17 do IEEE 1003.1e faz uma leitura interessante, e eu o recomendo. No apêndice B § 23.3, o grupo de trabalho fornece uma justificativa detalhada, de oito páginas, para a maneira um tanto complexa que as ACLs POSIX funcionam em relação aos antigos sinalizadores de permissão de grupo S_IRWXG . (Vale a pena notar que o pessoal da TRUSIX forneceu a mesma análise dez anos antes.) Eu não vou copiar tudo aqui. Leia o raciocínio no rascunho do padrão para detalhes. Aqui está um resumo muito breve :

• O manual do SunOS está errado. deve ler

  If you use the chmod(1) command to change the file group owner permissions on a file with ACL entries, either the file group owner permissions or the ACL mask are changed to the new permissions.

  Esse é o comportamento que você pode ver acontecendo , apesar do que a página de manual atual diz, em sua pergunta. É também o comportamento especificado pelo padrão POSIX do rascunho. Se houver uma entrada de controle de acesso CLASS_OBJ (terminologia da Sun e TRUSIX para ACL_MASK ), os bits de grupo de chmod() definem, senão eles configuram a entrada de controle de acesso GROUP_OBJ .

• Se este não fosse o caso, os aplicativos que faziam várias coisas padrão com 'chmod ()', esperando que funcionasse como 'chmod ()' tradicionalmente trabalhava em Unixes antigos não ACL, ou deixariam brechas na segurança ou ver o que eles pensam ser buracos de segurança:

  • Aplicativos Unix tradicionais esperam poder negar todo o acesso a um arquivo, pipe nomeado, dispositivo ou diretório com chmod(…,000) . Na presença de ACLs, isso desativará somente todas permissões de usuário e grupo se o antigo S_IRWXG mapear para CLASS_OBJ . Sem isso, definir as permissões de arquivo antigo como 000 não afetaria as entradas USER ou GROUP , e outros usuários, surpreendentemente, ainda teriam acesso ao objeto.

    Alterar temporariamente os bits de permissão de um arquivo para nenhum acesso com chmod 000 e alterá-los novamente era um antigo mecanismo de bloqueio de arquivos, usado antes de os Unixes obterem mecanismos de bloqueio consultivo, que - como você pode ver - as pessoas ainda usam hoje .

  • Scripts Unix tradicionais esperam poder executar chmod go-rwx e acabar com apenas o proprietário do objeto capaz de acessar o objeto. Novamente, - como você pode ver - essa ainda é a sabedoria recebida doze anos depois. E, novamente, isso não funciona, a menos que o antigo S_IRWXG mapeie para CLASS_OBJ se ele existir, porque senão esse comando chmod não desativaria nenhuma entrada de controle de acesso USER ou GROUP , levando aos usuários além do proprietário e dos grupos não proprietários que mantêm acesso a algo que é esperado para ser acessível somente ao proprietário.

  • Um sistema em que os bits de permissão eram separados e and ed com as ACLs exigiria que os sinalizadores de permissão de arquivo fossem rwxrwxrwx na maioria dos casos, o que poderia confundir os muitos aplicativos Unix que reclamam quando veja o que eles acham que é algo que pode ser escrito em um mundo.

    Um sistema em que os bits de permissão eram separados e or ed com as ACLs teria o problema chmod(…,000) mencionado antes.

Outras leituras

• Winfried Trümper (1999-02-28). Resumo sobre Posix.1e
• Comitê de Padrões de Aplicações Portáteis da IEEE Computer Society (outubro de 1997). Versão preliminar para tecnologia da informação - Interface de sistema operacional portátil (POSIX) - Parte 1 : Interface do Programa de Aplicação do Sistema (API) - Alteração Nº: Interfaces de Proteção, Auditoria e Controle [Linguagem C] IEEE 1003.1e. Rascunho 17.
• Craig Rubin (1989-08-18). Justificativa para a seleção de recursos de lista de controle de acesso para o sistema Unix . NCSC-TG-020-A. Publicação DIANE. ISBN 9780788105548.

Answer 2

Esse comportamento se aplica somente a entradas POSIX ACL. A razão disso é que se você tem uma pasta e dentro dessa pasta existe um arquivo, você pode usar como rwx (por exemplo) a pasta e o arquivo. Se as permissões de grupo do arquivo forem rw- (que podem ser como um cenário típico), a máscara fornecerá ao acl as permissões efetivas de rw - mesmo que a ACL indique explicitamente rwx.

Por outro lado, o diretório que quase sempre é + x tem permissões efetivas de máscara ACL também permitindo + x.

Em resumo, esta máscara é usada basicamente para diferenciar a permissão entre arquivos e pastas para o conjunto POSIX ACL, de modo que um arquivo não se torne executável quando normalmente não deveria ser.