Como o umask afeta as ACLs?

Alguém pode me explicar como umaskafeta a máscara padrão dos arquivos recém-criados se as ACLs estiverem ativadas? Existe alguma documentação sobre isso?

Exemplo:

$ mkdir test_dir && cd test_dir
$ setfacl -m d:someuser:rwx -m u:someuser:rwx .  # give access to some user
$ getfacl .
# file: .
# owner: myUsername
# group: myGroup
user::rwx
user:someuser:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:someuser:rwx
default:group::---
default:mask::rwx
default:other::---
$ umask # show my umask
077
$ echo "main(){}" > x.c # minimal C program
$ make x # build it
cc     x.c   -o x
$ getfacl x
# file: x
# owner: myUsername
# group: myGroup
user::rwx
user:someuser:rwx           #effective:rw-
group::---
mask::rw-
other::---

Eu esperaria mask:rwx. Na verdade, depois de definir umaskcomo, por exemplo 027, recebo o comportamento esperado.

Encontrei este exemplo, intitulado: ACL e MASK no linux . Neste artigo, são demonstrados os seguintes exemplos, que acho que ajudam a entender como as ACLs e umaskinteragem entre si.

fundo

Quando um arquivo é criado em um sistema Linux, as permissões padrão 0666são aplicadas, e quando um diretório é criado, as permissões padrão 0777são aplicadas.

exemplo 1 - arquivo

Suponha que definimos nossa umask como 077 e toque em um arquivo. Podemos usar stracepara ver o que realmente está acontecendo quando fazemos isso:

$ umask 077; strace -eopen touch testfile 2>&1 | tail -1; ls -l testfile
open("testfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
-rw-------. 1 root root 0 Sep 4 15:25 testfile

Neste exemplo, podemos ver que a chamada do sistema open()é feita com as permissões 0666, no entanto, quando umask 077é aplicada pelo kernel, as seguintes permissões são removidas ( ---rwxrwx) e ficamos com o rw-------aka 0600.

exemplo - diretório 2

O mesmo conceito pode ser aplicado aos diretórios, exceto que, em vez das permissões padrão serem 0666, elas são 0777.

$ umask 022; strace -emkdir mkdir testdir; ls -ld testdir
mkdir("testdir", 0777)                  = 0
drwxr-xr-x 2 saml saml 4096 Jul  9 10:55 testdir

Desta vez, estamos usando o mkdircomando O mkdircomando então chamou a chamada do sistema mkdir(). No exemplo acima, podemos ver que o mkdircomando chamou a mkdir()chamada de sistema com as permissões padrão 0777( rwxrwxrwx). Desta vez, com uma umask das 022seguintes permissões são removidas ( ----w--w-), então ficamos com 0755 ( rwxr-xr-x) quando os diretórios foram criados.

exemplo 3 (aplicando a ACL padrão)

Agora vamos criar um diretório e demonstrar o que acontece quando a ACL padrão é aplicada a ele, juntamente com um arquivo dentro dele.

$ mkdir acldir
$ sudo strace -s 128 -fvTttto luv setfacl -m d:u:nginx:rwx,u:nginx:rwx acldir

$ getfacl --all-effective acldir
# file: acldir
# owner: saml
# group: saml
user::rwx
user:nginx:rwx          #effective:rwx
group::r-x          #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:user:nginx:rwx      #effective:rwx
default:group::r-x      #effective:r-x
default:mask::rwx
default:other::r-x

Agora vamos criar o arquivo aclfile:

$ strace -s 128 -fvTttto luvly touch acldir/aclfile

# view the results of this command in the log file "luvly"
$ less luvly

Agora obtenha permissões do arquivo recém-criado:

$ getfacl --all-effective acldir/aclfile 
# file: acldir/aclfile
# owner: saml
# group: saml
user::rw-
user:nginx:rwx          #effective:rw-
group::r-x          #effective:r--
mask::rw-
other::r--

Observe a máscara mask::rw-. Por que não é mask::rwxcomo quando o diretório foi criado?

Verifique o luvlyarquivo de log para ver quais permissões padrão foram usadas para a criação do arquivo:

$ less luvly |grep open |tail -1
10006 1373382808.176797 open("acldir/aclfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 <0.000060>

É aqui que fica um pouco confuso. Com a máscara definida para rwxquando o diretório foi criado, você esperaria o mesmo comportamento para a criação do arquivo, mas não funciona dessa maneira. É porque o kernel está chamando a open()função com as permissões padrão de 0666.

Resumir

• Os arquivos não terão permissão de execução (mascarada ou eficaz). Não importa qual método usamos: ACL, umask ou mask & ACL.
• Os diretórios podem obter permissões de execução, mas isso depende de como o campo de máscara está definido.
• A única maneira de definir permissões de execução para um arquivo que está sob permissões da ACL é defini-las manualmente usando chmod.

Referências

• página de manual do acl

por questões de segurança, o sistema operacional linux não permite a criação automática de um arquivo com um bit de execução. Isso evita que os invasores cibernéticos gravem programas nesses arquivos e os executem se tiverem acesso ao seu servidor. É apenas uma precaução de segurança. Você sempre terá que definir manualmente o bit de execução nos arquivos após criá-los com o utilitário chmod