Historia
Originalmente, Unix solo tenía permisos para el usuario propietario y para otros usuarios:no había grupos. Ver la documentación de Unix versión 1, en particular chmod(1) . Entonces, la compatibilidad con versiones anteriores, al menos, requiere permisos para el usuario propietario.
Los grupos vinieron después. Las ACL que permitían 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 detallados que tener solo dos, a un costo muy bajo (mucho más bajo que las ACL). Por ejemplo, un archivo puede tener el modo rw-r----- :solo puede escribir el usuario propietario, puede leerlo un grupo.
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:admin solo permite usuarios en el admin grupo para ejecutar ese programa como root.
“Hay permisos que este esquema no puede expresar” es un terrible argumento en su contra. El criterio aplicable es ¿existen suficientes casos comunes expresables que justifiquen el costo? En este caso, el costo es mínimo, especialmente teniendo en cuenta las otras razones del usuario/grupo/otro tríptico.
Simplicidad
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 envío de correo electrónico) sabe que todo lo que necesita hacer es darle al archivo el modo 600. No necesita recorrer la base de datos del grupo buscando el grupo que solo contiene al usuario, y ¿Qué hacer si no hay tal grupo o hay más de uno?
Viniendo de otra dirección, suponga que ve un archivo y desea auditar sus permisos (es decir, verificar que sean lo que deberían ser). Es mucho más fácil cuando puede ir "solo accesible para el usuario, bien, siguiente" que cuando necesita rastrear a través de definiciones de grupo. (Tal complejidad es la ruina de los sistemas que hacen un uso intensivo de funciones avanzadas como ACL o capacidades).
Ortogonalidad
Cada proceso realiza accesos al sistema de archivos como un usuario en particular y un grupo en particular (con reglas más complicadas en los unice modernos, que admiten grupos complementarios). El usuario se usa 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 procesos y distinguir usuarios y grupos en permisos de sistemas de archivos.
¿Es este un diseño deliberado o un parche? Es decir, ¿los permisos de propietario/grupo se diseñaron y crearon junto con algún fundamento 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.
¿Existe un 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 a algunos archivos binarios/secuencias de comandos en un sistema acceso de solo ejecución a other y mantenga el acceso de lectura/escritura restringido a root .
No estoy seguro de lo que tiene en mente para un modelo de permiso del sistema de archivos que solo tiene permisos de propietario/grupo. No sé cómo podrías tener un sistema operativo seguro sin la existencia de un other categoría.
EDITAR: Supongamos que quisiste decir aquí group/other los permisos son todo lo que se necesitaría, entonces sugiero idear alguna forma de administrar las 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 user:user propiedad pero otros casos donde tiene sentido darle user:group propiedad.
archivos privados:muy fáciles de obtener al crear un grupo por usuario, algo que a menudo se hace en muchos sistemas.
De acuerdo, esto se hace fácilmente, pero se hace con la misma facilidad con la existencia de un other grupo...
permitir que solo el propietario (p. ej., el servicio del sistema) escriba en un archivo, permitir que solo cierto grupo lea y negar 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/grupo/otro 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 un other categoría en los permisos del sistema de archivos Unix.
Un diseño de sistema de archivos como el que parece estar contemplando (por lo que puedo decir) sería inseguro o difícil de manejar. Unix fue diseñado por personas muy inteligentes y creo que su modelo brinda el mejor equilibrio posible entre seguridad y flexibilidad.
¿Es este un diseño deliberado o un parche? Es decir, ¿los permisos de propietario/grupo se diseñaron y crearon junto con algún motivo 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 medía en KB y las CPU eran extremadamente lentas según los estándares actuales. El tamaño y la velocidad de dichas búsquedas eran importantes. Las ACL habrían requerido más espacio y habrían sido más lentas. Funcionalmente, el everyone El grupo está representado por las otras banderas de seguridad.
¿Existe un escenario en el que el esquema de usuario/grupo/otro sea útil pero el esquema de grupo/propietario no sea suficiente?
Los permisos que uso comúnmente para acceder a los archivos son:(estoy usando valores de bit por simplicidad y porque esa es la forma en que los configuro).
600o400:acceso de solo usuario (y sí, concedo acceso de solo lectura al usuario).640o660:acceso de usuarios y grupos.644,666o664:Usuario, grupo y otros accesos. Cualquier esquema de permisos de dos niveles solo puede manejar dos de estos tres casos. El tercero requeriría ACL.
Para directorios y programas suelo usar:
700o500:Acceso solo para usuarios750o710:Acceso solo para grupos755,777,775, o751:Usuario, grupo y otros accesos. Se aplican los mismos comentarios que para los archivos.
Los anteriores son los más utilizados, pero no son 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 ha señalado anteriormente, es muy fácil enumerar el permiso en una lista de directorio. Si no se utilizan 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.