CREATE ROLE — define un nuevo rol de base de datos
CREATE ROLEnombre[ [ WITH ]opción[ ... ] ] dondeopciónpuede ser: SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | REPLICATION | NOREPLICATION | BYPASSRLS | NOBYPASSRLS | CONNECTION LIMITlímite_conexiones| [ ENCRYPTED ] PASSWORD 'contraseña' | PASSWORD NULL | VALID UNTIL 'marca_temporal' | IN ROLEnombre_rol[, ...] | ROLEnombre_rol[, ...] | ADMINnombre_rol[, ...] | SYSIDuid
CREATE ROLE agrega un nuevo rol a un clúster de
bases de datos de PostgreSQL. Un rol es
una entidad que puede ser propietaria de objetos de base de datos y tener privilegios
en la misma; un rol puede considerarse un “usuario”, un “grupo”
o ambos, dependiendo de cómo se utilice. Consulta la
Chapter 21 y la Chapter 20
para obtener información sobre la gestión de usuarios y la autenticación.
Debes tener el privilegio CREATEROLE o ser un superusuario de la
base de datos para utilizar este comando.
Ten en cuenta que los roles se definen a nivel del clúster de bases de datos y, por lo tanto, son válidos en todas las bases de datos del clúster.
Durante la creación del rol, es posible asignarlo inmediatamente como
miembro de un rol existente, y también asignar roles existentes como
miembros del nuevo rol creado. Las reglas que determinan qué opciones iniciales
de pertenencia a un rol están habilitadas se describen a continuación en las cláusulas
IN ROLE, ROLE y ADMIN.
El comando GRANT tiene un control detallado de las opciones
durante la creación de la pertenencia, y la capacidad de modificar estas opciones
después de que se cree el nuevo rol.
nombreEl nombre del nuevo rol.
SUPERUSERNOSUPERUSER
Estas cláusulas determinan si el nuevo rol es un “superusuario”,
quien puede omitir todas las restricciones de acceso dentro de la base de datos.
El estado de superusuario es peligroso y debe usarse solo cuando sea realmente
necesario. Tú mismo debes ser un superusuario para crear un nuevo superusuario.
Si no se especifica, NOSUPERUSER es el valor por omisión.
CREATEDBNOCREATEDB
Estas cláusulas definen la capacidad de un rol para crear bases de datos. Si se
especifica CREATEDB, el rol que se está definiendo tendrá permitido
crear nuevas bases de datos. Especificar NOCREATEDB negará al rol la
capacidad de crear bases de datos. Si no se especifica, NOCREATEDB es
el valor por omisión. Solo los roles de superusuario o los roles con
CREATEDB pueden especificar CREATEDB.
CREATEROLENOCREATEROLE
Estas cláusulas determinan si a un rol se le permitirá crear, alterar, eliminar, comentar
y cambiar la etiqueta de seguridad de otros roles. Consulta la creación de roles
para obtener más detalles sobre qué capacidades confiere este privilegio.
Si no se especifica, NOCREATEROLE es el valor por omisión.
INHERITNOINHERIT
Esto afecta al estado de herencia de pertenencia cuando este rol se agrega como miembro
de otro rol, tanto en este como en futuros comandos. Específicamente, controla el estado
de herencia de las pertenencias agregadas con este comando usando la cláusula
IN ROLE, y en comandos posteriores usando la cláusula ROLE.
También se usa como el estado de herencia predeterminado al agregar este rol como miembro
usando el comando GRANT. Si no se especifica, INHERIT
es el valor por omisión.
En versiones de PostgreSQL anteriores a la 16, la herencia era un atributo a nivel de rol que controlaba todas las comprobaciones de pertenencia en tiempo de ejecución para ese rol.
LOGINNOLOGIN
Estas cláusulas determinan si se permite a un rol iniciar sesión; es decir, si el rol
se puede proporcionar como el nombre de autorización de sesión inicial durante la conexión
del cliente. Se puede pensar en un rol que tiene el atributo LOGIN
como un usuario. Los roles sin este atributo son útiles para gestionar privilegios de base
de datos, pero no son usuarios en el sentido habitual de la palabra. Si no se especifica,
NOLOGIN es el valor por omisión, excepto cuando CREATE ROLE
se invoca a través de su grafía alternativa CREATE USER.
REPLICATIONNOREPLICATION
Estas cláusulas determinan si un rol es un rol de replicación. Un rol debe tener este
atributo (o ser un superusuario) para poder conectarse al servidor en modo de replicación
(replicación física o lógica) y para poder crear o eliminar ranuras de replicación (replication slots).
Un rol que tiene el atributo REPLICATION es un rol con privilegios muy elevados
y solo debe usarse en roles realmente destinados a la replicación. Si no se especifica,
NOREPLICATION es el valor por omisión. Solo los roles de superusuario o los
roles con REPLICATION pueden especificar REPLICATION.
BYPASSRLSNOBYPASSRLS
Estas cláusulas determinan si un rol omite cada política de seguridad a nivel de fila (RLS).
NOBYPASSRLS es el valor por omisión. Solo los roles de superusuario o los
roles con BYPASSRLS pueden especificar BYPASSRLS.
Ten en cuenta que pg_dump establecerá row_security en OFF
por defecto, para asegurar que se vuelque todo el contenido de una tabla. Si el usuario que ejecuta
pg_dump no tiene los privilegios adecuados, se devolverá un error. Sin embargo, los superusuarios
y el propietario de la tabla que se está volcando siempre omiten RLS.
CONNECTION LIMIT límite_conexionesSi el rol puede iniciar sesión, esto especifica cuántas conexiones concurrentes puede realizar el rol. -1 (el valor por omisión) significa que no hay límite. Ten en cuenta que solo las conexiones normales cuentan para este límite. Ni las transacciones preparadas ni las conexiones de procesos de fondo (background workers) cuentan para este límite.
ENCRYPTED ] PASSWORD 'contraseña'PASSWORD NULL
Establece la contraseña del rol. (Una contraseña solo es de utilidad para roles que tienen
el atributo LOGIN, pero no obstante puedes definir una para roles que no lo
tengan). Si no planeas usar la autenticación por contraseña, puedes omitir esta opción.
Si no se especifica una contraseña, la contraseña se establecerá en null y la autenticación por
contraseña siempre fallará para ese usuario. Opcionalmente, una contraseña nula se puede escribir
explícitamente como PASSWORD NULL.
Especificar una cadena vacía también establecerá la contraseña en null, pero ese no era el caso antes de la versión 10 de PostgreSQL. En versiones anteriores, se podía usar una cadena vacía, o no, dependiendo del método de autenticación y la versión exacta, y libpq se negaría a usarla en cualquier caso. Para evitar la ambigüedad, debe evitarse especificar una cadena vacía.
La contraseña siempre se almacena cifrada en los catálogos del sistema. La palabra clave
ENCRYPTED no tiene efecto, pero se acepta para compatibilidad con versiones
anteriores. El método de cifrado se determina mediante el parámetro de configuración
password_encryption. Si la cadena de contraseña presentada ya está en
formato cifrado MD5 o SCRAM, se almacena tal cual independientemente de
password_encryption (ya que el sistema no puede descifrar la cadena de
contraseña cifrada especificada para cifrarla en un formato diferente). Esto permite recargar
contraseñas cifradas durante el volcado/restauración.
El soporte para contraseñas cifradas con MD5 está obsoleto y se eliminará en una versión futura de PostgreSQL. Consulta la Section 20.5 para obtener detalles sobre la migración a otro tipo de contraseña.
VALID UNTIL 'marca_temporal'
La cláusula VALID UNTIL establece una fecha y hora a partir de la cual la
contraseña del rol ya no es válida. Si se omite esta cláusula, la contraseña será válida indefinidamente.
IN ROLE nombre_rol
La cláusula IN ROLE hace que el nuevo rol se agregue automáticamente como
miembro de los roles existentes especificados. La nueva pertenencia tendrá la opción
SET habilitada y la opción ADMIN deshabilitada. La opción
INHERIT estará habilitada a menos que se especifique la opción
NOINHERIT.
ROLE nombre_rol
La cláusula ROLE hace que uno o más roles existentes especificados se agreguen
automáticamente como miembros, con la opción SET habilitada. Esto, en efecto,
convierte al nuevo rol en un “grupo”. Los roles nombrados en esta cláusula con el
atributo INHERIT a nivel de rol tendrán la opción INHERIT
habilitada en la nueva pertenencia. Las nuevas pertenencias tendrán la opción ADMIN
deshabilitada.
ADMIN nombre_rol
La cláusula ADMIN tiene el mismo efecto que ROLE, pero los
roles nombrados se agregan como miembros del nuevo rol con ADMIN habilitado,
otorgándoles el derecho de conceder la pertenencia en el nuevo rol a otros.
SYSID uid
La cláusula SYSID se ignora, pero se acepta para compatibilidad con versiones
anteriores.
Utiliza ALTER ROLE para cambiar los
atributos de un rol, y DROP ROLE para eliminar
un rol. Todos los atributos especificados por CREATE ROLE pueden modificarse por
comandos ALTER ROLE posteriores.
La forma preferida de agregar y eliminar miembros de roles que se están utilizando como grupos
es usar GRANT y
REVOKE.
La cláusula VALID UNTIL define un tiempo de expiración solo para la contraseña,
no para el rol en sí. En particular, el tiempo de expiración no se aplica cuando se inicia sesión
utilizando un método de autenticación que no sea basado en contraseña.
Los atributos de rol definidos aquí no son heredables; es decir, ser miembro de un rol con, por
ejemplo, CREATEDB no permitirá al miembro crear nuevas bases de datos, incluso
si la concesión de pertenencia tiene la opción INHERIT. Por supuesto, si la
concesión de pertenencia tiene la opción SET, el rol miembro podría ejecutar
SET ROLE al rol con privilegios de creación de base
de datos y luego crear una nueva base de datos.
Las concesiones de pertenencia creadas por las cláusulas IN ROLE, ROLE
y ADMIN tienen al rol que ejecuta este comando como el otorgante (grantor).
El atributo INHERIT es el valor por omisión por razones de compatibilidad con
versiones anteriores: en versiones previas de PostgreSQL, los usuarios
siempre tenían acceso a todos los privilegios de los grupos de los que eran miembros. Sin embargo,
NOINHERIT proporciona una coincidencia más cercana a la semántica especificada
en el estándar SQL.
PostgreSQL incluye un programa createuser que tiene
la misma funcionalidad que CREATE ROLE (de hecho, llama a este comando) pero puede
ejecutarse desde la consola de comandos.
La opción CONNECTION LIMIT solo se aplica de forma aproximada; si dos nuevas
sesiones comienzan aproximadamente al mismo tiempo cuando solo queda una ranura (“slot”)
de conexión para el rol, es posible que ambas fallen. Además, el límite nunca se aplica a los
superusuarios.
Se debe tener precaución al especificar una contraseña no cifrada con este comando. La contraseña
se transmitirá al servidor en texto plano, y también podría quedar registrada en el historial de
comandos del cliente o en el registro del servidor. Sin embargo, el comando
createuser transmite la contraseña cifrada. Además,
psql contiene el comando \password que se puede utilizar
para cambiar la contraseña de forma segura más adelante.
Crea un rol que pueda iniciar sesión, pero no le asigne una contraseña:
CREATE ROLE jonathan LOGIN;
Crea un rol con contraseña:
CREATE USER davide WITH PASSWORD 'jw8s0F4';
(CREATE USER es lo mismo que CREATE ROLE excepto que implica
LOGIN).
Crea un rol con una contraseña que es válida hasta finales de 2004. Después de transcurrido el primer segundo de 2005, la contraseña ya no será válida.
CREATE ROLE miriam WITH LOGIN PASSWORD 'jw8s0F4' VALID UNTIL '2005-01-01';
Crea un rol que pueda crear bases de datos y gestionar roles:
CREATE ROLE admin WITH CREATEDB CREATEROLE;
La sentencia CREATE ROLE está en el estándar SQL, pero el estándar solo requiere
la sintaxis:
CREATE ROLEnombre[ WITH ADMINnombre_rol]
La existencia de múltiples administradores iniciales y todas las demás opciones de
CREATE ROLE son extensiones de PostgreSQL.
El estándar SQL define los conceptos de usuarios y roles, pero los considera como conceptos distintos y deja que todos los comandos que definen usuarios sean especificados por cada implementación de base de datos. En PostgreSQL hemos optado por unificar usuarios y roles en una sola entidad. Por lo tanto, los roles tienen muchos más atributos opcionales que los que tienen en el estándar.
El comportamiento especificado por el estándar SQL se aproxima más estrechamente creando los usuarios
del estándar SQL como roles de PostgreSQL con la opción
NOINHERIT, y los roles del estándar SQL como roles de
PostgreSQL con la opción INHERIT.
La cláusula USER tiene el mismo comportamiento que ROLE pero
ha quedado obsoleta:
USER nombre_rol [, ...]
La cláusula IN GROUP tiene el mismo comportamiento que IN ROLE
pero ha quedado obsoleta:
IN GROUP nombre_rol [, ...]