¿Qué relaciones vinculan la máscara ACL y el permiso de grupo estándar en un archivo?

17

Al principio creo un archivo y verifico sus permisos estándar y entradas de ACL:

$ touch file; ls -l file; getfacl file
-rw-r--r-- 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
other::r--

Luego configuré la máscara de ACL en el archivo y nuevamente verifiqué sus permisos estándar y las entradas de ACL:

$ setfacl -m mask:rwx file
$ ls -l file; getfacl file
-rw-rwxr--+ 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

Tenga en cuenta que junto con la máscara de ACL, el permiso de grupo estándar en el archivo también cambió.

  1. ¿Qué conexión existe entre la máscara ACL y el permiso de grupo estándar?
  2. ¿Cuál es la razón para acoplar la máscara ACL y los permisos de grupo de archivos? ¿Qué lógica hay detrás de esto?

Las distribuciones en cuestión son Debian Linux 7.6 y CentOS 7


EDITAR

En este punto, solo quería compartir algunos hallazgos míos que se me ocurrieron mientras investigaba las relaciones entre los permisos de grupo de archivos estándar y la máscara ACL. Aquí están las observaciones empíricas que encontré:

  1. La máscara ACL se puede cambiar:

    1. configurándolo directamente con el setfacl -m m:<perms>comando;
    2. cambiando los permisos del grupo de archivos con el chmodcomando (si la máscara ACL ya está presente; puede que no esté presente porque es opcional si no hay permisos de ACL de usuario o grupo nombrados en el archivo);
    3. agregando una entrada de ACL de usuario o grupo con nombre (la máscara se volverá a calcular automáticamente).
  2. La máscara aplicará los derechos de acceso máximos (si hay entradas de ACL con permisos presentes que exceden los permisos de la máscara de ACL) solo si la máscara se configura directamente mediante setfacl o mediante la modificación del permiso del grupo de archivos con chmod (no se calcula automáticamente). Cualquier cambio en las entradas de ACL activará el recálculo automático de la máscara de ACL y desactivará efectivamente el "modo de aplicación".

  3. Hay un par de efectos secundarios que afectan implícitamente los permisos de grupo de archivos estándar cuando se usan ACL:

    1. La entrada de ACL de usuario o grupo designada aplicada a un archivo puede cambiar la máscara de ACL (aumentar sus permisos) y, por lo tanto, los permisos efectivos de grupo de archivos. Por ejemplo, si usted, como propietario de un archivo, tiene establecidos los permisos "rw-r - r-- jim students" y también le otorga permiso rw al usuario "jack", también otorgará implícitamente permisos rw a cualquier persona del grupo de "estudiantes".
    2. La máscara ACL más estricta (menos permisos) puede eliminar permanentemente los permisos de grupo de archivos estándar correspondientes. Por ejemplo, si tiene un archivo con permisos de grupo de archivos estándar rw y aplica una máscara ACL de solo lectura al archivo, sus permisos de grupo disminuirán a solo lectura. Luego, si elimina todas las entradas de ACL extendidas (con setfacl -bcomando), los permisos de grupo permanecerán como de solo lectura. Esto se aplica solo a la máscara ACL más estricta, la máscara ACL más suave (más permisos) no altera permanentemente el permiso del grupo de archivos original después de que se elimina.
golem
fuente
Creo que podría tomar la siguiente página como referencia, www-uxsup.csx.cam.ac.uk/pub/doc/suse/sles9/adminguide-sles9/…
kundy

Respuestas:

11

No tiene sentido si los permisos del archivo Unix no están de acuerdo con la entrada acl y viceversa. En consecuencia, la página del manual ( acl(5)) dice lo que pide:

CORRESPONDENCIA ENTRE INSCRIPCIONES ACL Y BITS DE PERMISO DE ARCHIVO

Los permisos definidos por las ACL son un superconjunto de los permisos especificados por los bits de permiso de archivo.

Existe una correspondencia entre el propietario del archivo, el grupo y otros permisos y entradas específicas de ACL: los permisos del propietario corresponden a los permisos de la entrada ACL_USER_OBJ. Si la ACL tiene una entrada ACL_MASK, los permisos del grupo corresponden a los permisos de la entrada ACL_MASK. De lo contrario, si la ACL no tiene una entrada ACL_MASK, los permisos del grupo corresponden a los permisos de la entrada ACL_GROUP_OBJ. Los otros permisos corresponden a los permisos de la entrada ACL_OTHER_OBJ.

El propietario del archivo, el grupo y otros permisos siempre coinciden con los permisos de la entrada de ACL correspondiente. La modificación de los bits de permiso de archivo da como resultado la modificación de las entradas de ACL asociadas, y la modificación de estas entradas de ACL resulta en la modificación de los bits de permiso de archivo.

Anexo en respuesta a la discusión:

¿Cuál es la razón para acoplar la máscara ACL y los permisos de grupo de archivos? ¿Qué lógica hay detrás de esto?

Una buena explicación está aquí . En esencia, la máscara es un

[...] límite superior de los permisos que otorgará cualquier entrada en la clase de grupo.

Esta propiedad de límite superior garantiza que las aplicaciones POSIX.1 que desconocen las ACL no comenzarán repentina e inesperadamente a otorgar permisos adicionales una vez que se admitan las ACL.

En las ACL mínimas, los permisos de clase de grupo son idénticos a los permisos de grupo propietario. En las ACL extendidas, la clase de grupo puede contener entradas para usuarios o grupos adicionales. Esto da como resultado un problema: algunas de estas entradas adicionales pueden contener permisos que no están contenidos en la entrada del grupo propietario, por lo que los permisos de entrada del grupo propietario pueden diferir de los permisos de la clase del grupo.

Este problema se resuelve por la virtud de la entrada de máscara. Con ACL mínimas, los permisos de clase de grupo se asignan a los permisos de entrada de grupo propietario. Con las ACL extendidas, los permisos de clase de grupo se asignan a los permisos de entrada de máscara, mientras que la entrada de grupo propietario todavía define los permisos de grupo propietario. La asignación de los permisos de clase de grupo ya no es constante.

contramodo
fuente
Lo que está diciendo se aplica a la siguiente salida getfacl: user :: rw- group :: r-- other :: r-- . Esas 3 líneas cambiarían si usa el chmodcomando para alterar los permisos estándar y viceversa cuando ejecute, por ejemplo getfacl -m u:someuser:rwx, el permiso de archivo estándar para el propietario del archivo cambiará y el cambio se reflejará en la ls -lsalida. Eso es todo cierto, pero no veo cómo responde a mi pregunta
Golem
mira mi edición para la historia completa
contramode
1
Su respuesta editada dice que hay un acoplamiento entre los permisos del grupo de archivos y la máscara ACL por diseño. La pregunta de cuál es la razón para acoplar la máscara ACL y los permisos de grupo de archivos aún está activa. Lo que la lógica subyace no me resulta claro.
golem
1
Podría tener sentido. Depende de la definición y la implementación. Por definición, el archivo ACL de Linux, tal como se implementa ahora, es un superconjunto de los permisos de archivo estándar, es decir, los incluye. Entonces no pueden "contradecir". Aquí hay un caso de uso. Si asigno permisos rwx a un " -rw-r--r-- 1 user userusuario de prueba" para el archivo con permisos iniciales , se aceptará la ACL de ese usuario nombrado, y la máscara ACL (junto con los permisos del grupo de archivos) también se alterará a rwx. --- [ver el siguiente comentario como continuación]
golem
1
Ahora, ¿los permisos rwx de "testuser" contradicen los nuevos -rw-rwxr-- 1 user userpermisos del archivo o no? ¿Cómo se determina la contradicción? ¿Al comparar los permisos de ACL de testuser con el permiso de grupo de archivos estándar? ¿Qué lógica te llevó a comparar los permisos de grupo con los permisos de usuario? ¿No son entidades diferentes? ¿No es contradictorio? Probablemente sea obvio para ti, pero todavía estoy luchando por comprenderlo.
golem
3

Finalmente entendí qué está ocurriendo exactamente cuando vi este enlace Manejando ACL

Específicamente, esas máscaras básicamente reemplazan y funcionan para reemplazar al USUARIO NOMBRADO y todos los permisos de GRUPO. Esto significa que si usted:

  1. ajusta la máscara, cambia los permisos máximos del grupo,
  2. si cambia cualquiera de los permisos de grupo con una máscara presente, la máscara toma los permisos de grupo máximos de todos los permisos de grupo
  3. los permisos de lectura, escritura y ejecución grupales se determinan en función de la máscara, si está presente

ingrese la descripción de la imagen aquí

Espero que esto ayude.

jjisnow
fuente
Hay una muy buena explicación de la máscara en la página que usted refirió (cita de la sección 27.3.3. Un directorio con ACL de acceso ): la máscara define los permisos máximos de acceso efectivo para todas las entradas en la clase de grupo. Esto incluye usuario con nombre, grupo con nombre y grupo propietario. .
patryk.beza
-1

¿Qué lógica hay detrás de esto?

La lógica está completamente rota y, por lo tanto, las ACL POSIX son tonterías puras e inútiles.

Si pretendían preservar la compatibilidad con aplicaciones que no tienen la noción de ACL excepto el modelo primitivo estándar "ugo" de UNIX, en realidad fallaron al principio porque ahora cada aplicación que borra los permisos del grupo está retirando efectivamente el acceso agregado por las ACL.

poige
fuente