Por que recebo permissão negada para um diretório com acl definido para o proprietário do diretório (depois de remover todas as permissões posix padrão)?

Por que recebo permissão negada para um diretório com acl definido para o proprietário do diretório (depois de remover todas as permissões posix padrão)?

Estou tentando executar o lscomando em um diretório que possui permissões acl para o proprietário e grupo do diretório (sem permissões posix padrão definidas). Isso resulta em uma Permissão negada, embora getfacldiga que o usuário deveria poder fazê-lo.

Aqui está o que estou fazendo:

  1. Crie um diretório e um arquivo dentro dele.

mkdir /tmp/mydir && touch /tmp/mydir/myfile

  1. Verifique se consigo executar lsneste diretório.
jgazula@gazula:/tmp$ ls -al /tmp/mydir/
total 896
drwxrwxr-x  2 jgazula jgazula   4096 Nov  1 11:57 .
drwxrwxrwt 25 root    root    909312 Nov  1 11:57 ..
-rw-rw-r--  1 jgazula jgazula      0 Nov  1 11:57 myfile
  1. Agora, vamos remover todas as permissões posix padrão neste diretório.

chmod 000 /tmp/mydir

  1. Verifique as permissões.
jgazula@gazula:/tmp$ ls -al /tmp | grep mydir
d---------  2 jgazula jgazula   4096 Nov  1 11:57 mydir
  1. Não deveríamos ser capazes lsagora.
jgazula@gazula:/tmp$ ls -al /tmp/mydir/
ls: cannot open directory '/tmp/mydir/': Permission denied
  1. Defina as permissões ACL para o jgazulausuário e o grupo.

sudo setfacl --mask -Rm u:jgazula:rwx,g:jgazula:rwx /tmp/mydir/

  1. Verifique as permissões acl.
jgazula@gazula:/tmp$ getfacl -ep /tmp/mydir/
# file: /tmp/mydir/
# owner: jgazula
# group: jgazula
user::---
user:jgazula:rwx        #effective:rwx
group::---          #effective:---
group:jgazula:rwx       #effective:rwx
mask::rwx
other::---
  1. Como as permissões ACL (incluindo as permissões efetivas) parecem boas, devo conseguir executar lsno diretório?
jgazula@gazula:/tmp$ ls -al /tmp/mydir/
ls: cannot open directory '/tmp/mydir/': Permission denied

Mas não posso e não entendo por quê.

  1. Curiosamente, quando verifico as permissões posix padrão, os bits de permissão do grupo foram definidos? Não tenho certeza se entendi por que apenas as permissões de grupo foram atualizadas.
jgazula@gazula:/tmp$ ls -al /tmp | grep mydir
d---rwx---+  2 jgazula jgazula   4096 Nov  1 12:13 mydir
  1. Vamos definir as permissões acl para o proprietário e grupo (ou seja, omitir o proprietário/grupo do comando).

sudo setfacl --mask -Rm u::rwx,g::rwx /tmp/mydir/

  1. Verifique as permissões acl novamente.
jgazula@gazula:/tmp$ getfacl -ep /tmp/mydir/
# file: /tmp/mydir/
# owner: jgazula
# group: jgazula
user::rwx
user:jgazula:rwx        #effective:rwx
group::rwx          #effective:rwx
group:jgazula:rwx       #effective:rwx
mask::rwx
other::---
  1. Verifique se posso executar lsagora.
jgazula@gazula:/tmp$ ls -al /tmp/mydir/
total 896
drwxrwx---+  2 jgazula jgazula   4096 Nov  1 11:57 .
drwxrwxrwt  25 root    root    909312 Nov  1 11:57 ..
-rwxrwxr--+  1 jgazula jgazula      0 Nov  1 11:57 myfile

Por que a etapa 6 não funciona sozinha? Estou definindo explicitamente as permissões ACL para um usuário e grupo. Por que preciso executar a etapa 11?

Responder1

Ao executar sudo setfacl --mask -Rm u:jgazula:rwx,g:jgazula:rwx /tmp/mydir/, você está criando uma ACL_USERentrada para o usuário jgazula. Mas o ACL_USER_OBJproprietário do arquivo ainda é ---. (Você pode ver isso na getfaclsaída da etapa 7.)

De acordo com man ACL, o algoritmo de verificação de acesso é:

1.   If the effective user ID of the process matches the user ID of the file object owner, then
           if the ACL_USER_OBJ entry contains the requested permissions, access is granted,
           else access is denied.

2.   else if the effective user ID of the process matches the qualifier of any entry of type ACL_USER, then
           if the matching ACL_USER entry and the ACL_MASK entry contain the requested permissions, access is granted,
           else access is denied.

Portanto, a ACL_USERentrada nunca é verificada.

Existe essencialmente a mesma pergunta sobre serverfault:ACL: dando - - - permissões para o proprietário do arquivo. (Mas parece que a resposta foi ACL_USERinvertida ACL_USER_OBJ.)

informação relacionada