¿Por qué chmod (1) en el grupo afecta la máscara de ACL?

Estoy tratando de entender este comportamiento de Unix (que estoy probando en Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Observe que el comando chmod (1) ha actualizado la máscara de ACL. ¿Por qué pasó esto?

La página de manual de SunOS tiene lo siguiente que decir:

Si utiliza el comando chmod (1) para cambiar los permisos del propietario del grupo de archivos en un archivo con entradas de ACL, tanto los permisos del propietario del grupo de archivos como la máscara de ACL se cambian a los nuevos permisos. Tenga en cuenta que los nuevos permisos de máscara de ACL pueden cambiar los permisos efectivos para usuarios y grupos adicionales que tienen entradas de ACL en el archivo.

Pregunto porque sería conveniente para mí si chmod (1) no tuviera este comportamiento. Espero que al comprender por qué hace lo que hace, pueda diseñar mejor cómo configuro los permisos del sistema de archivos.

Sería no ser conveniente para usted si chmod()no tienen este comportamiento.

Sería muy inconveniente, porque las cosas que las personas tradicionalmente esperan trabajar en Unixes se romperían. Este comportamiento te sirve bien, ¿lo sabías?

Es una pena que IEEE 1003.1e nunca se haya convertido en un estándar y se retiró en 1998. En la práctica, catorce años después, es un estándar que implementa una amplia gama de sistemas operativos, desde Linux a través de FreeBSD hasta Solaris .

El borrador de trabajo IEEE 1003.1e # 17 es una lectura interesante, y lo recomiendo. En el apéndice B § 23.3, el grupo de trabajo proporciona una justificación detallada de ocho páginas sobre la forma algo compleja en que las ACL de POSIX funcionan con respecto a las antiguas S_IRWXGmarcas de permiso de grupo. (Vale la pena señalar que las personas de TRUSIX proporcionaron el mismo análisis diez años antes). No voy a copiarlo todo aquí. Lea la justificación en el borrador del estándar para más detalles. Aquí hay un breve resumen :

• El manual de SunOS está mal. Se debe leer

  Si utiliza el chmod(1)comando para cambiar los permisos de propietario de grupos de archivos en un archivo con entradas de ACL, o bien los permisos de propietario de grupo de archivos o la máscara de ACL se cambian a los nuevos permisos.

  Este es el comportamiento que puede ver que sucede , a pesar de lo que dice la página del manual actual, en su pregunta. También es el comportamiento especificado por el borrador del estándar POSIX. Si existe una entrada de control de acceso ( CLASS_OBJla terminología de Sun y TRUSIX para ACL_MASK), los bits de grupo de un chmod()conjunto lo establecen; de lo contrario, establecen la GROUP_OBJentrada de control de acceso.

• Si este no fuera el caso, las aplicaciones que hicieron varias cosas estándar con `chmod ()`, esperando que funcione como `chmod ()` ha trabajado tradicionalmente en Unixes antiguos que no son ACL, dejarían huecos de seguridad o verían qué piensan que están abriendo agujeros de seguridad:

  • Las aplicaciones tradicionales de Unix esperan poder negar todo acceso a un archivo, canalización con nombre, dispositivo o directorio con chmod(…,000). En presencia de ACL, esto solo desactiva todos los permisos de usuarios y grupos si el antiguo se S_IRWXGasigna CLASS_OBJ. Sin esto, la configuración de los permisos de los archivos antiguos 000no afectaría a ninguna entrada USERni a ninguna GROUPotra y, sorprendentemente, otros usuarios aún tendrían acceso al objeto.

    Cambiar temporalmente los bits de permiso de un archivo para que no tenga acceso chmod 000y luego volver a cambiarlos era un viejo mecanismo de bloqueo de archivos, utilizado antes de que Unixes obtuviera mecanismos de bloqueo de asesoramiento, que , como puede ver, la gente todavía usa hoy en día .

  • Los scripts tradicionales de Unix esperan poder ejecutarse chmod go-rwxy terminar con solo el propietario del objeto capaz de acceder al objeto. Nuevamente , como pueden ver, esta sigue siendo la sabiduría recibida doce años después. Y de nuevo, esto no funciona a menos que los viejos S_IRWXGmapas a CLASS_OBJsi existe, porque de lo contrario que los chmodcomandos no se encendía alguna USERo GROUPde control de acceso entradas, lo que lleva a los usuarios menos al propietario y los grupos de retención acceso a algo que no propietario es Se espera que sea accesible solo para el propietario.

  • En la mayoría de los casos, un sistema en el que los bits de permiso estuvieran separados y andeditados con las ACL requeriría marcas de permiso de archivo rwxrwxrwx, lo que confundiría muchísimo a las muchas aplicaciones de Unix que se quejan cuando ven lo que piensan que se puede escribir en el mundo cosas.

    Un sistema en el que los bits de permiso estuvieran separados y oreditados con las ACL tendría el chmod(…,000)problema mencionado anteriormente.

Otras lecturas

• Winfried Trümper (1999-02-28). Resumen sobre Posix.1e
• Comité de Normas de Aplicaciones Portátiles de la IEEE Computer Society (octubre de 1997). Proyecto de Norma para Tecnología de la Información —Interfaz del sistema operativo portátil (POSIX) —Parte 1: Interfaz del programa de aplicación del sistema (API) - Enmienda N. °: Interfaces de protección, auditoría y control [Lenguaje C] IEEE 1003.1e. Borrador 17.
• Craig Rubin (18 de agosto de 1989). Justificación para seleccionar las características de la lista de control de acceso para el sistema Unix . NCSC-TG-020-A. DIANE Publishing. ISBN 9780788105548.

Este comportamiento solo se aplica a las entradas POSIX ACL. La razón por la que está aquí es si tiene una carpeta y dentro de esa carpeta existe un archivo, puede acl como rwx (por ejemplo) la carpeta y el archivo. Si los permisos de grupo del archivo son rw- (que podrían ser como un escenario típico), la máscara le otorga a acl los permisos efectivos de rw- aunque la ACL denota explícitamente rwx.

Por otro lado, el directorio que casi siempre es + x tiene permisos de máscara ACL efectivos que también permiten + x.

En resumen, esta máscara se usa básicamente para diferenciar el permiso entre archivos y carpetas para el conjunto de ACL POSIX para que un archivo no se vuelva ejecutable cuando normalmente no debería.