GRANT — definir privilegios de acceso
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER | MAINTAIN }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] nombre_tabla [, ...]
| ALL TABLES IN SCHEMA nombre_esquema [, ...] }
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( nombre_columna [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( nombre_columna [, ...] ) }
ON [ TABLE ] nombre_tabla [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { { USAGE | SELECT | UPDATE }
[, ...] | ALL [ PRIVILEGES ] }
ON { SEQUENCE nombre_secuencia [, ...]
| ALL SEQUENCES IN SCHEMA nombre_esquema [, ...] }
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
ON DATABASE nombre_base_de_datos [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON DOMAIN nombre_dominio [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN DATA WRAPPER nombre_fdw [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN SERVER nombre_servidor [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { { FUNCTION | PROCEDURE | ROUTINE } nombre_rutina [ ( [ [ modo_arg ] [ nombre_arg ] tipo_arg [, ...] ] ) ] [, ...]
| ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA nombre_esquema [, ...] }
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON LANGUAGE nombre_lenguaje [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
ON LARGE OBJECT loid [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { { SET | ALTER SYSTEM } [, ... ] | ALL [ PRIVILEGES ] }
ON PARAMETER parámetro_de_configuración [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
ON SCHEMA nombre_esquema [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE nombre_tablespace [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON TYPE nombre_tipo [, ...]
TO especificación_de_rol [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificación_de_rol ]
GRANT nombre_rol [, ...] TO especificación_de_rol [, ...]
[ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
[ GRANTED BY especificación_de_rol ]
donde especificación_de_rol puede ser:
[ GROUP ] nombre_rol
| PUBLIC
| CURRENT_ROLE
| CURRENT_USER
| SESSION_USER
El comando GRANT tiene dos variantes básicas: una
que otorga privilegios sobre un objeto de base de datos (tabla, columna, vista,
tabla foránea, secuencia, base de datos, envoltura de datos foráneos, servidor foráneo,
función, procedimiento, lenguaje procedimental, objeto grande, parámetro de
configuración, esquema, tablespace o tipo), y otra que otorga
membresía en un rol. Estas variantes son similares en muchos aspectos, pero
son lo suficientemente diferentes como para ser descritas por separado.
Esta variante del comando GRANT otorga privilegios
específicos sobre un objeto de base de datos a
uno o más roles. Estos privilegios se añaden
a los que ya han sido otorgados, si los hubiera.
La palabra clave PUBLIC indica que los
privilegios se otorgarán a todos los roles, incluidos aquellos que puedan
crearse posteriormente. PUBLIC puede pensarse como un
grupo definido implícitamente que siempre incluye a todos los roles.
Cualquier rol en particular tendrá la suma
de los privilegios otorgados directamente a él, los privilegios otorgados a cualquier rol
del cual sea miembro actualmente y los privilegios otorgados a
PUBLIC.
Si se especifica WITH GRANT OPTION, el destinatario
del privilegio puede a su vez otorgarlo a otros. Sin una opción de
otorgamiento (grant option), el destinatario no puede hacer eso. Las opciones de otorgamiento
no se pueden otorgar a PUBLIC.
Si se especifica GRANTED BY, el otorgante especificado debe
ser el usuario actual. Esta cláusula actualmente está presente en esta forma únicamente
por compatibilidad con SQL.
No es necesario otorgar privilegios al propietario de un objeto (usualmente el usuario que lo creó), ya que el propietario tiene todos los privilegios por omisión. (El propietario podría, sin embargo, optar por revocar algunos de sus propios privilegios por seguridad).
El derecho a eliminar un objeto, o a alterar su definición de cualquier manera, no se trata como un privilegio otorgable; es inherente al propietario y no se puede otorgar ni revocar. (Sin embargo, se puede obtener un efecto similar al otorgar o revocar la membresía en el rol propietario del objeto; ver más abajo). El propietario implícitamente también tiene todas las opciones de otorgamiento para el objeto.
Los privilegios posibles son:
SELECTINSERTUPDATEDELETETRUNCATEREFERENCESTRIGGERCREATECONNECTTEMPORARYEXECUTEUSAGESETALTER SYSTEMMAINTAINTipos específicos de privilegios, tal como se definen en la Section 5.8.
TEMP
Ortografía alternativa para TEMPORARY.
ALL PRIVILEGES
Otorga todos los privilegios disponibles para el tipo de objeto.
La palabra clave PRIVILEGES es opcional en
PostgreSQL, aunque el estándar SQL
estricto la requiere.
La sintaxis FUNCTION funciona para funciones simples,
funciones de agregación y funciones de ventana, pero no para procedimientos;
usa PROCEDURE para estos últimos.
Alternativamente, usa ROUTINE para hacer referencia a una función,
función de agregación, función de ventana o procedimiento, independientemente de su
tipo preciso.
También existe una opción para otorgar privilegios en todos los objetos del mismo
tipo dentro de uno o más esquemas. Esta funcionalidad actualmente se admite
solo para tablas, secuencias, funciones y procedimientos. ALL
TABLES también afecta a vistas y tablas foráneas, al igual que el
comando GRANT para objetos específicos. ALL
FUNCTIONS también afecta a funciones de agregación y de ventana, pero no a
procedimientos, de nuevo al igual que el comando GRANT
para objetos específicos. Usa ALL ROUTINES para incluir procedimientos.
Esta variante del comando GRANT otorga la membresía
en un rol a uno o más roles, y la modificación de las
opciones de membresía SET, INHERIT
y ADMIN; consulta la Section 21.3
para obtener detalles. La membresía en un rol es importante
porque potencialmente permite el acceso a los privilegios otorgados a un rol
a cada uno de sus miembros, y potencialmente también la capacidad de realizar cambios
en el rol mismo. Sin embargo, los permisos reales otorgados dependen de
las opciones asociadas con la concesión. Para modificar las opciones de
una membresía existente, simplemente especifica la membresía con los
valores de opción actualizados.
Cada una de las opciones descritas a continuación se puede establecer en
TRUE o FALSE. La palabra clave
OPTION se acepta como sinónimo de
TRUE, de modo que WITH ADMIN OPTION
es un sinónimo de WITH ADMIN TRUE. Al alterar
una membresía existente, la omisión de una opción da como resultado que se conserve el
valor actual.
La opción ADMIN permite al miembro otorgar a su vez
la membresía en el rol a otros, así como revocar la membresía en el rol.
Sin la opción admin, los usuarios comunes no pueden hacer eso. No se considera
que un rol posea WITH ADMIN OPTION sobre sí mismo.
Los superusuarios de la base de datos pueden otorgar o revocar la membresía en
cualquier rol a cualquiera. Esta opción tiene como valor por omisión
FALSE.
La opción INHERIT controla el estado de herencia
de la nueva membresía; consulta la Section 21.3 para
obtener detalles sobre la herencia. Si se establece en TRUE,
hace que el nuevo miembro herede del rol otorgado. Si se
establece en FALSE, el nuevo miembro no hereda.
Si no se especifica al crear una nueva membresía de rol, esta tiene como valor por omisión el
atributo de herencia del nuevo miembro.
La opción SET, si se establece en
TRUE, permite al miembro cambiar al rol otorgado
utilizando el comando
SET ROLE.
Si un rol es miembro indirecto de otro rol, puede usar
SET ROLE para cambiar a ese rol solo si hay una
cadena de concesiones en la que cada una tenga SET TRUE.
Esta opción tiene como valor por omisión TRUE.
Para crear un objeto propiedad de otro rol o dar la propiedad de un objeto existente
a otro rol, debes tener la capacidad de ejecutar SET
ROLE para ese rol; de lo contrario, comandos como ALTER
... OWNER TO o CREATE DATABASE ... OWNER
fallarán. Sin embargo, un usuario que hereda los privilegios de un rol pero no
tiene la capacidad de ejecutar SET ROLE para ese rol podría
obtener acceso completo al rol manipulando objetos existentes propiedad de ese
rol (por ejemplo, podría redefinir una función existente para que actúe como un
caballo de Troya). Por lo tanto, si los privilegios de un rol deben heredarse
pero no deben ser accesibles a través de SET ROLE, no debería
ser propietario de ningún objeto SQL.
Si se especifica GRANTED BY, la concesión se registra como
realizada por el rol especificado. Un usuario solo puede atribuir una concesión
a otro rol si posee los privilegios de ese rol. El rol registrado como otorgante
debe tener ADMIN OPTION en el rol objetivo, a menos que sea
el superusuario bootstrap. Cuando una concesión se registra con un otorgante distinto
del superusuario bootstrap, depende de que el otorgante continúe poseyendo
ADMIN OPTION en el rol; de modo que, si se revoca
ADMIN OPTION, las concesiones dependientes también deben ser revocadas.
A diferencia del caso de los privilegios, la membresía en un rol no se puede otorgar
a PUBLIC. Ten en cuenta también que esta forma del comando
no permite la palabra de adorno GROUP
en la especificación_de_rol.
El comando REVOKE se utiliza
para revocar privilegios de acceso.
Desde PostgreSQL 8.1, los conceptos de usuarios y
grupos se han unificado en un solo tipo de entidad llamada rol.
Por lo tanto, ya no es necesario utilizar la palabra clave GROUP
para identificar si un beneficiario es un usuario o un grupo. GROUP
todavía está permitido en el comando, pero es una palabra de adorno.
Un usuario puede realizar SELECT, INSERT, etc. en una
columna si posee ese privilegio ya sea para la columna específica o
para toda la tabla. Otorgar el privilegio a nivel de tabla y luego
revocarlo para una columna no hará lo que uno desearía: la
concesión a nivel de tabla no se ve afectada por una operación a nivel de columna.
Cuando alguien que no es propietario de un objeto intenta realizar un GRANT de privilegios
sobre el objeto, el comando fallará por completo si el usuario no tiene ningún
privilegio sobre el objeto. Siempre que haya algún privilegio
disponible, el comando procederá, pero otorgará solo aquellos
privilegios para los cuales el usuario tenga opciones de otorgamiento. Las formas de GRANT ALL
PRIVILEGES emitirán un mensaje de advertencia si no se poseen opciones de
otorgamiento, mientras que las otras formas emitirán una advertencia si no se poseen opciones de
otorgamiento para cualquiera de los privilegios específicamente nombrados en el comando.
(En principio, estas afirmaciones también se aplican al propietario del objeto, pero
dado que el propietario siempre se trata como si poseyera todas las opciones de otorgamiento, los
casos nunca pueden ocurrir).
Cabe señalar que los superusuarios de la base de datos pueden acceder a todos los
objetos independientemente de la configuración de privilegios del objeto. Esto
es comparable a los derechos de root en un sistema Unix.
Al igual que con root, no es prudente operar como superusuario
excepto cuando sea absolutamente necesario.
Si un superusuario decide ejecutar un comando GRANT o REVOKE,
el comando se realiza como si hubiera sido ejecutado por el
propietario del objeto afectado. In particular, los privilegios otorgados mediante
dicho comando parecerán haber sido otorgados por el propietario del objeto.
(Para la membresía de rol, la membresía parecerá haber sido otorgada
por el superusuario bootstrap).
GRANT y REVOKE también pueden ser realizados por un rol
que no es el propietario del objeto afectado, pero es miembro del rol que
posee el objeto, o es miembro de un rol que posee privilegios
WITH GRANT OPTION sobre el objeto. En este caso, los
privilegios se registrarán como otorgados por el rol que
realmente posee el objeto o posee los privilegios
WITH GRANT OPTION. Por ejemplo, si la tabla
t1 es propiedad del rol g1, del cual el rol
u1 es miembro, entonces u1 puede otorgar privilegios
sobre t1 a u2, pero esos privilegios parecerán
haber sido otorgados directamente por g1. Cualquier otro miembro
del rol g1 podría revocarlos más tarde.
Si el rol que ejecuta GRANT posee los privilegios requeridos
de forma indirecta a través de más de una ruta de membresía de rol, no se especifica
cuál de los roles contenedores se registrará como el que realizó la concesión. En tales
casos, la mejor práctica es usar SET ROLE para convertirse en el
rol específico como el cual deseas realizar el GRANT.
Otorgar permisos en una tabla no extiende automáticamente los
permisos a ninguna secuencia utilizada por la tabla, incluidas
las secuencias vinculadas a columnas de tipo SERIAL. Los permisos en las
secuencias deben establecerse por separado.
Consulta la Section 5.8 para obtener más información sobre los tipos de privilegios específicos, así como sobre cómo inspeccionar los privilegios de los objetos.
Otorgar el privilegio de inserción a todos los usuarios en la tabla films:
GRANT INSERT ON films TO PUBLIC;
Otorgar todos los privilegios disponibles al usuario manuel en la vista
kinds:
GRANT ALL PRIVILEGES ON kinds TO manuel;
Ten en cuenta que, si bien lo anterior efectivamente otorgará todos los privilegios si es ejecutado por un
superuser o por el propietario de kinds, cuando sea ejecutado por otra persona
solo otorgará aquellos permisos para los cuales esa otra persona tenga
opciones de otorgamiento.
Otorgar la membresía en el rol admins al usuario joe:
GRANT admins TO joe;
Según el estándar SQL, la palabra clave PRIVILEGES
en ALL PRIVILEGES es requerida. El
estándar SQL no admite establecer los privilegios en más de
un objeto por comando.
PostgreSQL permite que el propietario de un objeto revoque sus
propios privilegios comunes: por ejemplo, el propietario de una tabla puede hacer que la tabla
sea de solo lectura para sí mismo revocando sus propios privilegios INSERT,
UPDATE, DELETE y TRUNCATE.
Esto no es posible según el estándar SQL. La razón es que PostgreSQL
trata los privilegios del propietario como si hubieran sido otorgados por el propietario a sí mismo;
por lo tanto, también puede revocarlos. En el estándar SQL, los privilegios del propietario son
otorgados por una entidad supuesta llamada “_SYSTEM”. Al no ser
“_SYSTEM”, el propietario no puede revocar estos derechos.
Según el estándar SQL, las opciones de otorgamiento se pueden otorgar a
PUBLIC; PostgreSQL solo admite otorgar opciones de otorgamiento
a roles.
El estándar SQL permite que la opción GRANTED BY especifique
únicamente CURRENT_USER o
CURRENT_ROLE. Las otras variantes son extensiones de
PostgreSQL.
El estándar SQL proporciona un privilegio USAGE
en otros tipos de objetos: conjuntos de caracteres, colaciones,
traducciones.
En el estándar SQL, las secuencias solo tienen un privilegio USAGE,
el cual controla el uso de la expresión NEXT VALUE FOR,
la cual es equivalente a la función nextval en PostgreSQL.
Los privilegios de secuencia SELECT y UPDATE son
extensiones de PostgreSQL. La aplicación del privilegio USAGE
de secuencia a la función currval también es una extensión de PostgreSQL
(al igual que la función misma).
Los privilegios en bases de datos, tablespaces, esquemas, lenguajes y parámetros de configuración son extensiones de PostgreSQL.