¿Hay alguna razón por la cual existen los permisos de "propietario"? ¿No son suficientes los permisos de grupo?

21

Creo que más bien entiendo cómo funcionan los permisos de archivos en Linux. Sin embargo, no entiendo por qué se dividen en tres niveles y no en dos.

Me gustaría responder a los siguientes problemas:

  • ¿Es este diseño deliberado o un parche? Es decir, ¿se diseñaron y crearon los permisos del propietario / grupo junto con alguna justificación o vinieron uno tras otro para responder a una necesidad?
  • ¿Hay algún escenario en el que el esquema de usuario / grupo / otro sea útil pero un esquema de grupo / otro no sea suficiente?

Las respuestas a la primera deben citar libros de texto o paneles de discusión oficiales.

Los casos de uso que he considerado son:

  • archivos privados: muy fácilmente obtenibles haciendo un grupo por usuario, algo que a menudo se hace como en muchos sistemas.
  • permitiendo que solo el propietario (p. ej., el servicio del sistema) escriba en un archivo, permitiendo que solo un determinado grupo lea y denegue todos los demás accesos; el problema con este ejemplo es que una vez que el requisito es que un grupo tenga acceso de escritura, el usuario / group / other falla con eso. La respuesta para ambos es usar ACL y no justifica, en mi humilde opinión, la existencia de permisos de propietario.

Nota: he refinado esta pregunta después de haber cerrado la pregunta en superuser.com .

EDIT corregido "pero un esquema de grupo / propietario no será suficiente" a "... grupo / otro ...".

linux permissions Yuval
fuente
1
Realmente no entiendo por qué crees que los permisos de grupo serían suficientes. Imagine una situación en la que desea permitir que sus desarrolladores tengan sus propios archivos privados (configuraciones, etc.), pero también desea permitirles compartir código entre ellos. Tener un devsgrupo lo permite.
Chris Down
@ChrisDown Está diciendo que haría que el usuario sea foomiembro de grupos fooy que devsasigne archivos compartidos al devgrupo y archivos privados al foogrupo
Michael Mrozek
44
Mientras lo hace, ¿por qué tener permisos mundiales en lugar de solo un grupo 'todos' del que todos son miembros? La respuesta es que la configuración de permisos de usuario / grupo / otro se inventó antes de las ACL.
Random832

Respuestas:

24

Historia

Originalmente, Unix solo tenía permisos para el usuario propietario y para otros usuarios: no había grupos. Consulte la documentación de Unix versión 1, en particular chmod(1). Por lo tanto, la compatibilidad con versiones anteriores, por lo menos, requiere permisos para el usuario propietario.

Los grupos vinieron después. Las ACL que permiten involucrar a más de un grupo en los permisos de un archivo llegaron mucho más tarde.

Poder expresivo

Tener tres permisos para un archivo permite permisos más finos que tener solo dos, a un costo muy bajo (mucho más bajo que las ACL). Por ejemplo, un archivo puede tener modo rw-r-----: solo el usuario propietario puede escribirlo, un grupo puede leerlo.

Otro caso de uso son los ejecutables setuid que solo son ejecutables por un grupo. Por ejemplo, un programa con modo rwsr-x---propiedad de root:adminsolo permite a los usuarios del admingrupo ejecutar ese programa como root.

"Hay permisos que este esquema no puede expresar" es un argumento terrible en su contra. El criterio aplicable es, ¿hay suficientes casos comunes que puedan justificar el costo? En este caso, el costo es mínimo, especialmente dadas las otras razones para el usuario / grupo / otro tríptico.

Sencillez

Tener un grupo por usuario tiene una sobrecarga de administración pequeña pero no insignificante. Es bueno que el caso extremadamente común de un archivo privado no dependa de esto. Una aplicación que crea un archivo privado (por ejemplo, un programa de entrega de correo electrónico) sabe que todo lo que necesita hacer es darle al archivo el modo 600. No necesita atravesar la base de datos del grupo buscando el grupo que solo contiene al usuario, y ¿Qué hacer si no hay tal grupo o más de uno?

Si viene desde otra dirección, suponga que ve un archivo y desea auditar sus permisos (es decir, verifique que sean lo que deberían ser). Es mucho más fácil cuando puede ir "solo accesible para el usuario, bien, luego" que cuando necesita rastrear las definiciones de grupo. (Tal complejidad es la ruina de los sistemas que hacen un uso intensivo de características avanzadas como ACL o capacidades).

Ortogonalidad

Cada proceso realiza accesos al sistema de archivos como un usuario particular y un grupo particular (con reglas más complicadas en unidades modernas, que admiten grupos suplementarios). El usuario se utiliza para muchas cosas, incluidas las pruebas de root (uid 0) y el permiso de entrega de señal (basado en el usuario). Existe una simetría natural entre distinguir usuarios y grupos en permisos de proceso y distinguir usuarios y grupos en permisos de sistema de archivos.

Gilles 'SO- deja de ser malvado'
fuente
Excelente respuesta, y disfruté aprendiendo sobre los hombres mayores. Sin embargo, tengo algunas reservas sobre lo que dijiste. Un sistema más simple, que en realidad puede hacer casi (si no exactamente) tanto como las ACL, es dejar que cada uno de los permisos 'rwx' lleve un grupo (en lugar de al revés). Es decir, tendrá un grupo de lectura, un grupo de escritura y un grupo de ejecución. Si realmente es necesario para fines del sistema operativo, puede adjuntar un propietario al archivo. De esa manera, también puede especificar un grupo especial 'propietario' y un grupo 'todos'. Aparte de la jerarquía, creo que esto cubre todo, incluida la simplicidad y la ortogonalidad.
Yuval
1
@Yuval Lo que está describiendo es un sistema ACL, el mismo que el de Linux, excepto que no tiene la capacidad directa de asignar permisos a un usuario.
Gilles 'SO- deja de ser malvado'
Eso puede ser. Lo que traté de enfatizar es que actualmente cada registro de archivo contiene dos ID (grupo, propietario) y una máscara de bits. ¿No sería más efectivo (nuevamente, el argumento de costo / ganancia) simplemente tener cuatro ID? (ejecutar grupo, leer grupo, escribir grupo, propietario)
Yuval
@Yuval ¿Por qué cuatro ID? Eso sería mucho más restrictivo que las ACL (porque necesitaría root para definir un grupo para cada conjunto), y apenas más flexible que los permisos actuales de Unix (distinguir entre lectura y ejecución es extremadamente raro, y para la escritura a menudo querría la unión del grupo de lectura y el grupo de escritura). Si permite una lista de grupos para cada permiso, y una lista de usuarios por si acaso (porque no siempre hay el grupo correcto, no todos los sistemas tienen un grupo por usuario), básicamente tiene ACL Solaris / Linux.
Gilles 'SO- deja de ser malvado'
Usted argumenta que lo que describí es una ACL, pero esto significa que el esquema de permisos de Linux actual es una ACL para discapacitados, que solo puede tener un registro de usuario, un registro de grupo y un registro para Todos (para usar la jerga de Windows). Sugerí modificar la discapacidad para personas reorganizando la semántica. En lugar de prescribir entidades, prescriba permisos. Esta podría ser la forma en que se implementan las ACL tradicionales, no lo sé. El punto es que se trata de un costo mínimo, en términos de almacenamiento y simplicidad, en comparación con el estado actual, todavía ortogonal, pero con todo el poder expresivo de las ACL.
Yuval
10

¿Es este diseño deliberado o un parche? Es decir, ¿se diseñaron y crearon los permisos del propietario / grupo junto con alguna justificación o vinieron uno tras otro para responder a una necesidad?

Los permisos de usuario / grupo / otros en un archivo son parte del diseño original de Unix.

¿Hay algún escenario en el que el esquema de usuario / grupo / otro sea útil pero un esquema de grupo / propietario no sea suficiente?

Sí, prácticamente todos los escenarios que podría imaginar donde la seguridad y el control de acceso son importantes.

Ejemplo: es posible que desee otorgar algunos archivos binarios / scripts en un sistema de acceso de solo ejecución othery mantener restringido el acceso de lectura / escritura root.

No estoy seguro de lo que tiene en mente para un modelo de permisos del sistema de archivos que solo tiene permisos de propietario / grupo. No sé cómo podría tener un sistema operativo seguro sin la existencia de una othercategoría.

EDITAR: suponiendo group/otherque quisieras decir que aquí los permisos son todo lo que se necesitaría, entonces sugiero idear alguna forma de administrar claves criptográficas o una forma en que solo los usuarios correctos puedan acceder a su cola de correo. Hay casos en los que una clave privada puede necesitar estrictamente la user:userpropiedad, pero otros casos en los que tiene sentido otorgarle la user:grouppropiedad.

archivos privados: muy fácilmente obtenibles haciendo un grupo por usuario, algo que a menudo se hace como en muchos sistemas.

Es cierto que esto se hace fácilmente, pero es igual de fácil con la existencia de un othergrupo ...

permitiendo que solo el propietario (p. ej., el servicio del sistema) escriba en un archivo, permitiendo que solo un determinado grupo lea y denegue todos los demás accesos ; el problema con este ejemplo es que una vez que el requisito es que un grupo tenga acceso de escritura, el usuario / group / other falla con eso. La respuesta para ambos es usar ACL y no justifica, en mi humilde opinión, la existencia de permisos de propietario.

He resaltado la parte de su declaración que parece reiterar mi punto sobre la necesidad lógica de una othercategoría en los permisos del sistema de archivos Unix.

Tal diseño de sistema de archivos como parece estar contemplando (por lo que puedo decir) sería inseguro o difícil de manejar. Unix fue diseñado por algunas personas muy inteligentes, y creo que su modelo ofrece el mejor equilibrio posible de seguridad y flexibilidad.

Charles Boyd
fuente
1
Creo que "grupo / propietario" era un error tipográfico destinado a ser "grupo / otro"
Random832
Ah, probablemente tengas razón! En ese caso, agregaré otro contraejemplo.
Charles Boyd el
3
Como puede leer The UNIX Time-Sharing System, escrito por Dennis M. Ritchie y Ken Thomson en 1974, originalmente, había 7 bits para permisos: Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users.(el séptimo bit era el setuidbit).
Carlos Campderrós
4

¿Es este diseño deliberado o un parche? Es decir, ¿se diseñaron y crearon los permisos del propietario / grupo junto con alguna justificación o vinieron uno tras otro para responder a una necesidad?

Sí, este es un diseño deliberado que ha estado presente en UNIX desde los primeros días. Se implementó en sistemas donde la memoria se midió en KB y las CPU eran extremadamente lentas para los estándares actuales. El tamaño y la velocidad de tales búsquedas fueron importantes. Las ACL hubieran requerido más espacio y hubieran sido más lentas. Funcionalmente, el everyonegrupo está representado por las otras banderas de seguridad.

¿Hay algún escenario en el que el esquema de usuario / grupo / otro sea útil pero un esquema de grupo / propietario no sea suficiente?

Los permisos que uso habitualmente para acceder a los archivos son: (Estoy usando valores de bits por simplicidad y porque esa es la forma en que generalmente los configuro).

  • 600o 400: Acceso de solo usuario (y sí, otorgo acceso de solo lectura al usuario).
  • 640o 660: acceso de usuarios y grupos.
  • 644, 666o 664: Usuario, grupo y otro acceso. Cualquier esquema de permisos de dos niveles solo puede manejar dos de estos tres casos. El tercero requeriría ACL.

Para directorios y programas que uso habitualmente:

  • 700o 500: acceso solo de usuario
  • 750o 710: Acceso solo grupal
  • 755, 777, 775, O 751: usuario, grupo, y otro acceso. Se aplican los mismos comentarios que para los archivos.

Los anteriores son los más utilizados, pero no una lista exhaustiva de la configuración de permisos que uso. Los permisos anteriores combinados con un grupo (a veces con un bit de grupo fijo en los directorios) han sido suficientes en todos los casos en los que podría haber usado una ACL.

Como se señaló anteriormente, es muy fácil incluir el permiso en una lista de directorios. Si no se usan ACL, puedo auditar los permisos de acceso con solo una lista de directorios. Cuando trabajo con sistemas basados ​​en ACL, me resulta muy difícil verificar o auditar los permisos.

BillThor
fuente
3

El sistema de permisos de usuario / grupo / otro fue diseñado antes de que se inventaran las ACL. Se remonta a los primeros días de UNIX, por lo que no puede decir que el problema debería resolverse con ACL. Incluso si el concepto de una ACL parece obvio, habría implicado una cantidad significativa [por el día] de sobrecarga adicional para almacenar y administrar una cantidad variable de información de permisos con cada archivo, en lugar de una cantidad fija.

El uso de ACL para todo también significa que no tiene un subconjunto bien definido de la información de permisos que se puede mostrar "de un vistazo". La salida para ls -lmuestra los permisos estándar (usuario / grupo / otro), el nombre del usuario y el grupo, y una notación adicional (por ejemplo, +o @signo) en las entradas que tienen una ACL asociada a ellos, todo en una línea. Su sistema requeriría que identifique los "dos primeros grupos" en la ACL para proporcionar una funcionalidad equivalente.

Como punto adicional, un archivo aún necesita tener un propietario en el modelo UNIX porque las ACL de UNIX no proporcionan quién puede modificar la ACL.

Aleatorio832
fuente