tipos - ¿Por qué PostgreSQL fusionó usuarios y grupos en roles?
usuarios y roles en postgresql (4)
Encontré este hilo en la lista de PostgreSQL-Hackers , del 6 de junio de 2003, que al final sugiere que los usuarios y grupos y roles se consoliden. (Gracias Craig Ringer por sugerir que revise los archivos de la lista pgsql-hackers).
Aquí hay algunos beneficios mencionados (los que encontré).
Permita que los grupos tengan grupos como miembros
el código ACL se simplificaría
la sintaxis GRANT / REVOKE y el formato de visualización de las listas de ACL podrían simplificarse, ya que no habría necesidad de un marcador sintáctico en cuanto a si un nombre de pila es un usuario o un grupo.
En algunas circunstancias, podría ver que tiene sentido permitir el inicio de sesión directamente como un grupo / rol / quéhacerlo
Esto también resolvería el problema de que las vistas de information_schema mostrarán solo objetos propios
[hace que sea más fácil] representar privilegios otorgados a grupos [ya que simplemente reutilizaría el código relacionado con el rol]
De los documentos de PostgreSQL :
El concepto de roles subsume los conceptos de "usuarios" y "grupos". En las versiones de PostgreSQL anteriores a la 8.1, los usuarios y los grupos eran tipos distintos de entidades, pero ahora solo hay roles. Cualquier rol puede actuar como un usuario, un grupo o ambos.
¿Por qué hicieron este cambio en 8.1?
Tal vez es más fácil desde el punto de vista de los codificadores de C, con una sola clase de Rol (struct)?
CREATE USER is equivalent to CREATE ROLE except that CREATE USER otorga el permiso LOGIN al usuario / rol .
(Estoy a punto de diseñar un sistema de permisos para mi aplicación web, por lo tanto, estoy interesado en esto).
Del manual :
El estándar SQL define los conceptos de usuarios y roles, pero los considera como conceptos distintos y deja todos los comandos que definen a los usuarios a ser especificados por cada implementación de la base de datos. En PostgreSQL, hemos elegido unificar usuarios y roles en un solo tipo de entidad. Por lo tanto, los roles tienen muchos más atributos opcionales que los que tienen en el estándar.
Tener una distinción entre usuarios y grupos no te gana nada.
AFAIK la motivación para cambiarlo fue simplificar usos como:
Un usuario que se hace pasar por otro, por ejemplo, un superusuario que simula un usuario con permisos reducidos. Con los roles unificados, esto se convierte en un cambio más de la función actual, no diferente del grupo primario cambiante.
Grupos que son miembros de otros grupos para implementar permisos de acceso granulares.
Sin embargo, si desea conocer los detalles, es mejor que revise los archivos de la lista pgsql-hackers del período y el historial de git (convertido a partir de CVS).
La fusión tiene muchas ventajas y ninguna desventaja. Por ejemplo, ahora puede convertir sin problemas un "usuario" a un "grupo" y viceversa agregando / eliminando el privilegio de LOGIN .
ALTER ROLE myrole LOGIN;
ALTER ROLE myrole NOLOGIN;
O puede otorgar membresía en cualquier otro inicio de sesión ("usuario") o rol que no sea de inicio de sesión ("grupo") a un rol:
GRANT joe TO sue;
Todavia puedes:
CREATE USER james;
Eso es solo un rol con el privilegio de iniciar sesión ahora. O:
CREATE GROUP workers;
Eso es efectivamente lo mismo que CREATE ROLE ahora.
El manual lo tiene todo.