La cuestión es que siempre pensé que estos permisos colapsan entre sí, comenzando con el más general (otro -> grupo -> usuario).
Si fuera el caso, entonces los permisos "otros" se aplicarían a todos.
En otras palabras, si o = rwx, ¿a quién le importa cuáles son los requisitos para el grupo y el usuario?
Eso es diferente de tu oración anterior. Aquí está insinuando que los permisos están unidos, por ejemplo, que userX tiene el permiso de lectura si userX posee el archivo y el archivo es legible por el usuario, o si un grupo al que pertenece userX posee el archivo y el archivo es group legible, o si el archivo es legible de otra manera. Pero no es así como funciona. De hecho, o=rwx
significa que los rwx
permisos se aplican a otros, pero no dice nada sobre entidades que no son otras.
Primero, no importa directamente a qué grupos pertenece un usuario. El núcleo no tiene una noción de usuarios que pertenecen a grupos. Lo que el núcleo mantiene es, para cada proceso, una ID de usuario (el UID efectivo ) y una lista de ID de grupo (el GID efectivo y los GID suplementarios). Los grupos se determinan en el momento del inicio de sesión, mediante el proceso de inicio de sesión: es el proceso de inicio de sesión que lee la base de datos del grupo (por ejemplo /etc/group
). Las identificaciones de usuarios y grupos son heredadas por procesos secundarios¹.
Cuando un proceso intenta abrir un archivo, con los permisos tradicionales de Unix:
- Si el usuario propietario del archivo es el UID efectivo del proceso, entonces se utilizan los bits de permiso del usuario.
- De lo contrario, si el grupo propietario del archivo es el GID efectivo del proceso o una de las ID de grupo suplementarias del proceso, se utilizan los bits de permiso de grupo.
- De lo contrario, se utilizan los otros bits de permiso.
Solo se utiliza un conjunto de bits rwx. El usuario tiene prioridad sobre el grupo que tiene prioridad sobre otros. Cuando hay listas de control de acceso , el algoritmo descrito anteriormente se generaliza:
- Si hay una ACL en el archivo para el UID efectivo del proceso, entonces se usa para determinar si se otorga el acceso.
- De lo contrario, si hay una ACL en el archivo para el GID efectivo del proceso o una de las ID de grupo suplementarias del proceso, se utilizan los bits de permiso de grupo.
- De lo contrario, se utilizan los otros bits de permiso.
Consulte también Precedencia de ACLS cuando un usuario pertenece a varios grupos para obtener más detalles sobre cómo se utilizan las entradas de ACL, incluido el efecto de la máscara.
Por lo tanto, -rw----r-- alice interns
indica un archivo que puede ser leído y escrito por Alice, y que puede ser leído por todos los demás usuarios, excepto los pasantes. Un archivo con permisos y propiedad ----rwx--- alice interns
es accesible solo para pasantes, excepto Alice (ya sea que sea pasante o no). Dado que Alice puede llamar chmod
para cambiar los permisos, esto no proporciona ninguna seguridad; Es un caso de borde. En los sistemas con ACL, el mecanismo generalizado permite eliminar permisos de usuarios específicos o grupos específicos, lo que a veces es útil.
Usar un solo conjunto de bits, en lugar de ordenar todos los bits para cada acción (leer, escribir, ejecutar), tiene varias ventajas:
- Tiene el efecto útil de permitir la eliminación de permisos de un conjunto de usuarios o grupos, en sistemas con ACL. En sistemas sin ACL, los permisos se pueden eliminar de un grupo.
- Es más sencillo de implementar: verifique un conjunto de bits, en lugar de combinar varios conjuntos de bits.
- Es más simple analizar los permisos de un archivo, porque hay menos operaciones involucradas.
¹ Pueden cambiar cuando se ejecuta un proceso setuid o setgid. Esto no está relacionado con el problema en cuestión.