Início / unix / Perguntas / 475698
Accepted
arif
Asked: 2018-10-16 15:29:42 +0800 CST

Qual é o propósito exato de `mask` na ACL do sistema de arquivos?

  • 772

Quando aplico a ACL padrão em um diretório, vejo default:maskou apenas masknos dois cenários a seguir.

Cenário 1

-bash-4.2$ ls -ld test/
 drwxr-x---. 2 test test 4096 Oct 15 19:12 test/

-bash-4.2$ setfacl -d -m u:arif:rwx test/

-bash-4.2$ getfacl --omit-header test
 user::rwx
 group::r-x
 other::---
 default:user::rwx
 default:user:arif:rwx
 default:group::r-x
 default:mask::rwx
 default:other::---

Cenário 2

-bash-4.2$ ls -dl dir/
 drwxr-x---. 2 test test 4096 Oct 15 18:17 dir/

-bash-4.2$ getfacl dir
 # file: dir
 # owner: test
 # group: test
 user::rwx
 group::r-x
 other::---

-bash-4.2$ setfacl -m user:arif:rwx dir

-bash-4.2$ getfacl --omit-header dir
 user::rwx
 user:arif:rwx
 group::r-x
 mask::rwx
 other::---

Então, qual é o propósito maskdaqui?

linux permissions

1 respostas

  1. Best Answer

    o que

    Este sistema ACL de 3 bits tem suas raízes no TRUSIX. Outros sistemas ACL, como os do estilo NFS4 no FreeBSD, MacOS, AIX, Illumos e Solaris, funcionam de maneira diferente e esse conceito de entrada de controle de acesso de máscara não está presente.

    A máscara é, como o nome diz, uma máscara que é aplicada para mascarar as permissões concedidas pelas entradas de controle de acesso para usuários e grupos. É a permissão máxima que pode ser concedida por qualquer entrada de controle de acesso, exceto por um proprietário de arquivo ou uma entrada "outra". Seus 3 bits são andeditados com os 3 bits dessas outras entradas.

    Assim, por exemplo, se um usuário for concedido rw-por uma entrada de controle de acesso, mas a máscara for r--, o usuário só terá r--acesso de fato. Por outro lado, se um usuário for concedido apenas --xpor uma entrada de controle de acesso, uma máscara de rwxnão concederá permissões extras e o usuário terá apenas --xacesso.

    A máscara padrão em um diretório pai é a configuração de máscara aplicada às coisas criadas nele. É uma forma de herança.

    Por que

    É uma pena que o IEEE 1003.1e nunca tenha se tornado um padrão e tenha sido retirado em 1998. Na prática, dezenove anos depois, é um padrão que uma ampla gama de sistemas operacionais - do Linux ao FreeBSD ao Solaris (além das ACLs do estilo NFS4 no últimos casos) — realmente implementam.

    O rascunho de trabalho nº 17 da IEEE 1003.1e é uma leitura interessante, e eu a 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 como as ACLs POSIX funcionam com relação aos antigos S_IRWXGsinalizadores de permissão de grupo. (Vale a pena notar que o pessoal da TRUSIX forneceu praticamente a mesma análise dez anos antes.) Isso cobre a razão de ser da máscara, que vou apenas resumir aqui.

    • Os 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 só desativa todas as permissões de usuário e grupo se houver uma máscara e os S_IRWXGmapas antigos para ela. Sem isso, definir as permissões do arquivo antigo como 000não afetaria nenhum não proprietário userou groupentradas e outros usuários, surpreendentemente, ainda teriam acesso ao objeto.

      Alterar temporariamente os bits de permissão de um arquivo para sem acesso chmod 000e depois alterá-los novamente era um mecanismo de bloqueio de arquivo antigo, usado antes que o Unixes ganhasse mecanismos de bloqueio consultivos, que - como você pode ver - as pessoas ainda usam mesmo no século 21 . (O bloqueio consultivo tem sido facilmente utilizável a partir de scripts com ferramentas portáteis conhecidas, como setlockdesde o final da década de 1990.)

    • Os scripts tradicionais do Unix esperam poder ser executados chmod go-rwxe acabam com apenas o proprietário do objeto capaz de acessá-lo. Novamente, isso não funciona a menos que haja uma máscara e as S_IRWXGpermissões antigas sejam mapeadas para ela; porque, caso contrário, esse chmodcomando não desativaria nenhuma entrada de não proprietário userou groupde controle de acesso, fazendo com que outros usuários que não o proprietário e os grupos não proprietários retivessem o acesso a algo que se espera que seja acessível apenas ao proprietário.

      E novamente – como você pode ver – esse tipo de chmodcomando ainda era a sabedoria recebida doze anos depois. A lógica ainda se mantém.

    • Outras abordagens sem um mecanismo de máscara apresentam falhas.
    • Um sistema alternativo em que os bits de permissão fossem separados e andeditados com as ACLs exigiria que os sinalizadores de permissão de arquivo fossem rwxrwxrwxna maioria dos casos, o que confundiria muitos aplicativos Unix que reclamam quando veem o que pensam ser mundial. coisas graváveis.
    • Um sistema alternativo em que os bits de permissão fossem separados e oreditados com as ACLs teria o chmod(…,000)problema mencionado anteriormente.

    Daí um sistema ACL com uma máscara.

    Leitura adicional

    • 9

relate perguntas