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

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 ...".

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.

¿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.

¿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.

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.