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.
fuente
Respuestas:
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_IRWXG
marcas 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
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_OBJ
la terminología de Sun y TRUSIX paraACL_MASK
), los bits de grupo de unchmod()
conjunto lo establecen; de lo contrario, establecen laGROUP_OBJ
entrada 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 seS_IRWXG
asignaCLASS_OBJ
. Sin esto, la configuración de los permisos de los archivos antiguos000
no afectaría a ninguna entradaUSER
ni a ningunaGROUP
otra 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 000
y 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-rwx
y 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 viejosS_IRWXG
mapas aCLASS_OBJ
si existe, porque de lo contrario que loschmod
comandos no se encendía algunaUSER
oGROUP
de 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
and
editados con las ACL requeriría marcas de permiso de archivorwxrwxrwx
, 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
or
editados con las ACL tendría elchmod(…,000)
problema mencionado anteriormente.Otras lecturas
fuente
S_IRWXG
permisos. Llámame cuando hayas terminado.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.
fuente