Esta es la pregunta que enfrenté en una entrevista como administrador del sistema.
Si no configuramos el valor de la máscara, ¿cuál es el valor predeterminado de la máscara?
Estaba pensando que si no configuramos la máscara, debería ser rwx , ¿no?
Por ejemplo:
> touch testfile
> getfacl testfile
# file: testfile
# owner: chenicha
# group: csgrad
user::rw-
group::r--
other::r--
Incluso si no indicaba el estado de la máscara, pero asumo que debería ser rwx , ¿verdad?
Si no aplica ningún tipo de ACL , entonces no habrá necesidad de un mask . De acuerdo con this ,
La entrada de la máscara se crea automáticamente cuando es necesario pero no se proporciona.
Y de acuerdo con this Si usa ACL mínimo, no se agregará ninguna máscara.
[arif@arif blabla]$ ls -ldha .
drwxrwxr-x. 2 arif arif 4.0K Oct 17 06:13 .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rwx
other::r-x
[arif@arif blabla]$ chmod g-wx .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::r--
other::r-x
[arif@arif blabla]$ setfacl -m g::rw .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rw-
other::r--
Según this ,
Las ACL extendidas también contienen una entrada de máscara y pueden contener cualquier cantidad de entradas de usuarios y grupos nombrados.
Así que ahora, usaremos ACL extendido que da como resultado group class permisos asignados a la entrada mask porque como se mencionó here ,
En las ACL mínimas, los permisos de clase de grupo son idénticos a los permisos de grupo propietarios. En las ACL extendidas, la clase de grupo puede contener entradas para usuarios o grupos adicionales. Esto genera un problema: algunas de estas entradas adicionales pueden contener permisos que no están contenidos en la entrada de grupo propietaria, por lo que los permisos de entrada de grupo propietaria pueden diferir de los permisos de clase de grupo.
Este problema se resuelve por la virtud de la entrada de máscara. Con las ACL mínimas, los permisos de clase de grupo se asignan a los permisos de entrada de grupo propietarios. 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 propietaria aún define los permisos de grupo de propiedad.
[arif@arif blabla]$ setfacl -m g:wheel:rw .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rw-
group:wheel:rw-
mask::rw-
other::r--
Aquí, puede ver que el valor del permiso de clase de grupo se asigna al mask a pesar de definir cualquier mask específico. Y este enfoque de mapeo asegura la interacción fluida de las aplicaciones, independientemente de si tienen soporte de ACL. La razón para usar group class permission bits como mask se describe en Documentación TRUSIX de la siguiente manera,
Los bits de permiso de clase de grupo de archivos son el campo de enmascaramiento preferido, aunque fomentan el acceso predeterminado permisivo por parte del grupo propietario. Esta elección debe realizarse porque el uso de la clase de propietario del archivo causaría problemas de compatibilidad en los programas que intentan establecer el acceso de "solo propietario", mientras que la designación del archivo que otra clase podría dejar objetos abiertos para atacar se eliminó o nunca presente. Una opción adicional de enmascarar las entradas de usuario con los bits de permiso de clase de propietario del archivo y las entradas de grupo con los bits de permiso de clase de grupo de archivos tiene las mismas desventajas que la máscara contra solo la clase de propietario de archivo.
Creo que podría haber dicho que el valor predeterminado de mask es el mismo que el valor de permiso group class .
Lea otras preguntas en las etiquetas linux unix access-control