Precedencia del usuario y propietario del grupo en los permisos de archivo

Me encontré con algo inesperado (para mí) con respecto a los permisos de archivos en Linux (Arch Linux). Básicamente tengo:

• userX en groupX
• fileX userX:groupX ---rwx----

Lo que me desconcierta: no puedo realizar ninguna acción ( rwx) en fileX. ¿Es esto correcto? ¿Alguien puede confirmar que este es realmente el comportamiento esperado?

Las únicas acciones que puedo realizar son mvy rmporque tengo permisos de escritura en el directorio principal.

La cuestión es que siempre pensé que estos permisos colapsan entre sí, comenzando con el más general (otro -> grupo -> usuario). En otras palabras, si a o=rwxquién le importa cuáles son las transferencias para el grupo y el usuario. Aparentemente este no es el caso, pero no tiene mucho sentido para mí; Parece contradictorio. Lo único en lo que este enfoque parece ser útil es excluir fácilmente a una persona / grupo muy específico, lo que no parece una forma inteligente de hacerlo (en mi humilde opinión). Además, el propietario (¿y el grupo?) Debería poder de chmodtodos modos, ¿verdad? ¿Alguna idea sobre este asunto?

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=rwxsignifica que los rwxpermisos 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 internsindica 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 internses accesible solo para pasantes, excepto Alice (ya sea que sea pasante o no). Dado que Alice puede llamar chmodpara 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.}

Los permisos más específicos tienen prioridad sobre los menos específicos.

userX en groupX

fileX userX: groupX --- rwx ----

Como usted es el propietario del archivo, solo se le otorgarán permisos de propietario. El propietario no tiene permisos. Por lo tanto, no puedes hacer nada. Si no hubiera sido el propietario del archivo y un miembro del grupo, se aplicarían los permisos del grupo.

Por favor lea esta sección de la página wiki

https://en.wikipedia.org/wiki/File_system_permissions#Classes

-rwxrw---- significa que el propietario tiene permisos de lectura, escritura y ejecución, el grupo tiene lectura y escritura, y otros no tienen permisos.

Los permisos que proporcionó otorgan al grupo 'groupX' permisos para leer, escribir y ejecutar el archivo. Si usted es miembro del grupo "groupX" pero no es el propietario del archivo, estos permisos se aplicarán a usted.

En este caso, supongo que usted es el propietario del archivo. Solo los permisos establecidos para el propietario se aplicarán a usted. Por supuesto, el propietario puede anular o cambiar los permisos en el archivo. El grupo, sin embargo, no puede hacer esto. Por ejemplo, vim le pedirá que confirme si está escribiendo en un archivo para el que no tiene permisos de escritura pero del que es propietario.

Usualmente leo permisos de izquierda a derecha. ¿Soy el dueño? En caso afirmativo, se aplican los permisos del propietario. Si no; ¿Soy miembro del grupo? En caso afirmativo, se aplican los permisos de grupo. Si no, entonces los permisos para "Otro" se aplican a mí.

En algunos casos, es útil ser el propietario de un archivo pero no tener permisos de escritura. Le protege de borrar o modificar accidentalmente el archivo. Personalmente, he establecido el permiso 400 en todos mis archivos de plantilla, solo para asegurarme de no modificarlos por accidente. Lo mismo se aplica a los permisos de ejecución.

Pude agregar un usuario a un grupo, otorgarle permisos de grupo a un directorio (070) y luego DESPUÉS DE REINICIAR pude acceder a la carpeta.

Crear grupo: sudo groupadd groupname

Agregar usuario al grupo: sudo gpasswd -a nombre de usuario nombre de grupo

Asegúrese de que todo el directorio esté bajo la propiedad correcta del grupo (debe ser miembro actual de groupname para realizar): sudo chgrp -R groupname directorio_ruta /

Dé solo el grupo rwx para la carpeta (podría ser rw, ajuste según sea necesario): sudo chmod -R 070 directory_path

Después de hacer lo anterior, asegúrese de cerrar sesión y volver a iniciarla. Si eso no funciona, reinicie la máquina. Hacer esto funcionó para mí.