effective los permisos se forman haciendo AND entre los permisos reales (¿reales?) con el mask . Desde el mask de su archivo es rw- , todos los effective los permisos tienen el x bit apagado.
Respuesta corta:si desea una máscara con el bit de ejecución activado, debe configurarlo explícitamente usando setfacl después de touch . La seguridad prohíbe su configuración implícita.
setfacl -n -m m::rwx foo
"-n" para suprimir el recálculo de la máscara (puede no ser necesario).
"m::rwx" establece el valor de la máscara en 'rwx'. Tenga en cuenta que "m::x" deshabilitaría todas las lecturas y escrituras.
No puedo mostrar por qué la máscara es "rw-". Supongo que el directorio predeterminado donde touch crea el archivo permanece sin cambios durante todo el ejemplo de OP.
-
La entrada de directorio para 'foo' debería mostrar el propietario 'root' (debido al comando sudo y el grupo 'guards' porque el directorio tiene el bit SUID establecido. Los permisos serán predeterminados '-rw-...r--' con los permisos de grupo del directorio '-...r-x...' (debido a que el bit SUID se muestra como una pequeña s).
-
Luego vienen las ACL, que deberían ser el directorio predeterminado. Dado que las ACL se heredan, no esperaría que se creara ninguna ACLe y que la máscara ACLE sea el directorio predeterminado, 'rwx'.
Pero si se crean, espero que los nuevos ACLe se preparen desde el valor predeterminado, dejando nuevamente la máscara en 'rwx'. Si no están preparados a partir de los valores predeterminados, esto parecería anular la idea de una ACL predeterminada:la ACL "predeterminada" solo proporcionaría ACL de usuario y grupo con nombre.
Esto ahora plantea la pregunta de cuál debería ser la máscara ACLe. Espero que sea 'rwx' de la entrada de máscara predeterminada. Pero podría crearse con una máscara en blanco, y luego se aplica todo tipo de jerga legal.
- Con una ACL tentativa de usuario::rw-, grupo::r-x, otro::r--, grupo:rueda:rwx, grupo:guardias:rwx y máscara:::(sin configurar), consultamos el documentación para
setfacl, asumiendo que se aplican las mismas reglas a la creación de archivos.
Hay una cláusula:
Si una ACL contiene entradas de usuario o grupo con nombre y no existe ninguna entrada de máscara, se crea una entrada de máscara que contiene los mismos permisos que la entrada de grupo.
Esto establecería la máscara ACL en "r-x", si la entrada del grupo ACL se creó a partir de la entrada del directorio de archivos, o "r-x" si la entrada del grupo ACL provino de la ACL predeterminada. (De otra manera, para este caso, el resultado es el mismo).
También hay una cláusula:
Si una ACL predeterminada contiene entradas de usuario con nombre o entradas de grupo con nombre, y no existe ninguna entrada de máscara, se agrega una entrada de máscara que contiene los mismos permisos que la entrada de grupo de la ACL predeterminada predeterminada. ... los permisos de la entrada de máscara se ajustan aún más para incluir la unión de todos los permisos afectados por la entrada de máscara.
Si se aplica esta regla, la máscara comenzará como "r-x" (misma lógica) que la cláusula anterior), y luego se ajustará para que sea la "unión de todos los permisos afectados por la entrada de la máscara".
"permisos afectados por la entrada de máscara" no está definido en el setfacl documentación de mando. La documentación de POSIX ACL dice:
La máscara es la combinación de todos los permisos de acceso del grupo propietario y todas las entradas de usuarios y grupos.
Dé la palabra "unión", que es aditiva, leería "combinación" como un o-ing lógico. En otras palabras, si algún grupo o usuario ACLe tiene permiso "x", la máscara contendrá "x".
- Según toda esta lógica, el valor de la máscara en el ejemplo del OP debe ser 'rwx', sin importar qué ruta lógica se haya seguido.
El razonamiento anterior debe ser erróneo, ya que la x de ejecutar no aparece en la máscara.
Por lo tanto, debe haber alguna regla sobre cómo se calcula la máscara que se ha "ocultado" de las fuentes de documentación comunes (o hemos encontrado un error).
Mi conclusión es que la 'x' siempre se elimina incondicionalmente y la documentación es laxa.
Este cambio probablemente se realizó con la justificación de la "seguridad":ningún archivo debe ser implícitamente ejecutable, pero debe tener el bit ejecutable activado después de su creación.