¿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.

linux permissions posix acl jofel
fuente

Con un umask de 077, obtendrás un mask::rw-. Pero esa no es realmente tu pregunta, ¿correcto?

slm

@slm Esto es parte de mi pregunta. Quiero saber cómo la máscara de los nuevos archivos depende de la umask. Me sorprendió bastante que con 077 obtengo mask::rw-y no mask::rwxcuál era la máscara predeterminada del directorio.

jofel

OK, estoy actualizando mi respuesta ahora con ejemplos que deberían ayudar a aclarar esto. Dame un par de minutos.

slm

Esta pregunta está estrechamente relacionada.

jofel

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

slm
fuente

@ jofel: avíseme si esto tiene sentido.

slm

@Smm, muchas gracias por tu respuesta detallada. Me acerca a mi problema real: el permiso de grupo en chmod syscall afecta la máscara del archivo ( chmod("file",0760)-> mask:rw, chmod("file",0770)-> mask:rwx). Tal vez debería comenzar una nueva pregunta sobre esto ...

jofel

@jofel: sí, eso suena como otra pregunta.

slm

@sIm y ya se respondió aquí .

jofel

"Cuando se crea un archivo en un sistema Linux, se aplican los permisos predeterminados 0666 ..." , bueno, eso no es exactamente correcto, ya que depende de la aplicación de creación.

ilkkachu

¿Cómo afecta umask a las ACL?

Respuestas:

Antecedentes

ejemplo 1 - archivo

ejemplo - 2 directorio

ejemplo 3 (Aplicación de ACL predeterminada)

Para resumir

Referencias