¿Cómo afecta umask a las ACL?

¿Puede alguien explicarme cómo umaskafecta la máscara predeterminada de los archivos recién creados si las ACL están activadas? ¿Hay alguna documentación sobre esto?

Ejemplo:

$ 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::---

Yo esperaría mask:rwx. En realidad, después de configurar, umaskpor ejemplo 027, obtengo el comportamiento esperado.

Encontré este ejemplo, titulado: ACL y MASK en Linux . En este artículo se demuestran los siguientes ejemplos que creo que ayudan a comprender cómo umaskinteractúan los ACL e interactúan entre sí.

Antecedentes

Cuando se crea un archivo en un sistema Linux, 0666se aplican los permisos predeterminados, mientras que cuando se crea un directorio, 0777se aplican los permisos predeterminados .

ejemplo 1 - archivo

Supongamos que configuramos nuestra umask en 077 y tocamos un archivo. Podemos usar stracepara ver qué sucede realmente cuando hacemos esto:

$ 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

En este ejemplo, podemos ver que la llamada al sistema open()se realiza con los permisos 0666, sin embargo, cuando umask 077el núcleo la aplica, los siguientes permisos se eliminan ( ---rwxrwx) y nos queda con rw-------aka 0600.

ejemplo - 2 directorio

El mismo concepto se puede aplicar a los directorios, excepto que en lugar de que los permisos predeterminados sean 0666, son 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

Esta vez estamos usando el mkdircomando. El mkdircomando luego llamó a la llamada al sistema mkdir(). En el ejemplo anterior, podemos ver que el mkdircomando llamó a la llamada al mkdir()sistema con los permisos predeterminados 0777( rwxrwxrwx). Esta vez con una umask de 022los siguientes permisos se eliminan ( ----w--w-), por lo que nos queda 0755 ( rwxr-xr-x) cuando se crean los directorios.

ejemplo 3 (Aplicación de ACL predeterminada)

Ahora creemos un directorio y demostremos qué sucede cuando se le aplica la ACL predeterminada junto con un archivo dentro.

$ 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

Ahora creemos el archivo aclfile:

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

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

Ahora obtenga permisos del archivo recién creado:

$ 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--

Note la máscara, mask::rw-. ¿Por qué no es mask::rwxcomo cuando se creó el directorio?

Verifique el luvlyarchivo de registro para ver qué permisos predeterminados se usaron para la creación del archivo:

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

Aquí es donde se pone un poco confuso. Con la máscara establecida rwxcuando se creó el directorio, esperaría el mismo comportamiento para la creación del archivo, pero no funciona de esa manera. Es porque el núcleo está llamando a la open()función con los permisos predeterminados de 0666.

Para resumir

• Los archivos no obtendrán permiso de ejecución (enmascaramiento o efectivo). No importa qué método usemos: ACL, umask o mask & ACL.
• Los directorios pueden obtener permisos de ejecución, pero depende de cómo se configure el campo de enmascaramiento.
• La única forma de establecer permisos de ejecución para un archivo que está bajo permisos ACL es configurarlos manualmente usando chmod.

Referencias

• página de manual de acl

Por razones de seguridad, el sistema operativo Linux no permite la creación automática de un archivo con un bit de ejecución. Esto es para evitar que los ciberatacantes escriban programas en dichos archivos y los ejecuten si obtienen acceso a su servidor. Es solo una precaución de seguridad. Siempre tendrá que configurar manualmente el bit de ejecución en los archivos después de crearlos con la utilidad chmod