Como o umask afeta as ACLs?

Question

Alguém pode me explicar como umask afeta a máscara padrão de arquivos recém-criados se as ACLs são 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 umask para, por exemplo 027 obtenho o comportamento esperado.

    

Answer 1

Eu encontrei este exemplo, intitulado: ACL e MASK no linux . Neste artigo, os exemplos a seguir são demonstrados, o que ajuda a entender como as ACLs e umask interagem umas com as outras.

Antecedentes

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

exemplo 1 - arquivo

Suponha que definimos nossa umask para 077 e tocamos em um arquivo. Podemos usar strace para 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 o umask 077 é aplicado pelo kernel, as seguintes permissões são removidas ( ---rwxrwx ) e ficamos com rw------- aka 0600.

exemplo - 2 diretório

O mesmo conceito pode ser aplicado aos diretórios, exceto que, em vez de as 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 comando mkdir . O comando mkdir , em seguida, chamou a chamada do sistema mkdir() . No exemplo acima, podemos ver que o comando mkdir chamou a chamada do sistema mkdir() com as permissões defaul 0777 ( rwxrwxrwx ). Desta vez com uma umask de 022 as seguintes permissões foram removidas ( ----w--w- ), então ficamos com 0755 ( rwxr-xr-x ) quando os diretórios foram criados.

exemplo 3 (Aplicando ACL padrão)

Agora vamos criar um diretório e demonstrar o que acontece quando a ACL padrão é aplicada a ela junto com um arquivo dentro dela.

$ 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::rwx como quando o diretório foi criado?

Verifique o arquivo de log luvly 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 é um pouco confuso. Com a máscara definida como rwx quando 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 função open() com as permissões padrão de 0666 .

Para resumir

• Os arquivos não receberão permissão de execução (mascaramento ou efetivo). 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 mascaramento está definido.
• A única maneira de definir permissões de execução para um arquivo que está sob permissões de ACL é defini-las manualmente usando chmod .

Referências

• página do manual do acl

Answer 2

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 serve para evitar que os hackers 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 em arquivos depois de criá-los com o utilitário chmod