When an object is created, it is assigned an owner. The owner is normally the role that executed the creation statement. For most kinds of objects, the initial state is that only the owner (or a superuser) can do anything with the object. To allow other roles to use it, privileges must be granted.

There are different kinds of privileges: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE, SET, ALTER SYSTEM, and MAINTAIN. The privileges applicable to a particular object vary depending on the object's type (table, function, etc.). More detail about the meanings of these privileges appears below. The following sections and chapters will also show you how these privileges are used.

The right to modify or destroy an object is inherent in being the object's owner, and cannot be granted or revoked in itself. (However, like all privileges, that right can be inherited by members of the owning role; see Section 21.3.)

An object can be assigned to a new owner with an ALTER command of the appropriate kind for the object, for example

ALTER TABLE table_name OWNER TO new_owner;

Superusers can always do this; ordinary roles can only do it if they are both the current owner of the object (or inherit the privileges of the owning role) and able to SET ROLE to the new owning role. All object privileges of the old owner are transferred to the new owner along with the ownership.

To assign privileges, the GRANT command is used. For example, if joe is an existing role, and accounts is an existing table, the privilege to update the table can be granted with:

GRANT UPDATE ON accounts TO joe;

Writing ALL in place of a specific privilege grants all privileges that are relevant for the object type.

The special “role” name PUBLIC can be used to grant a privilege to every role on the system. Also, “group” roles can be set up to help manage privileges when there are many users of a database — for details see Chapter 21.

To revoke a previously-granted privilege, use the fittingly named REVOKE command:

REVOKE ALL ON accounts FROM PUBLIC;

Ordinarily, only the object's owner (or a superuser) can grant or revoke privileges on an object. However, it is possible to grant a privilege “with grant option”, which gives the recipient the right to grant it in turn to others. If the grant option is subsequently revoked then all who received the privilege from that recipient (directly or through a chain of grants) will lose the privilege. For details see the GRANT and REVOKE reference pages.

El propietario de un objeto puede optar por revocar sus propios privilegios ordinarios, por ejemplo para hacer que una tabla sea de solo lectura tanto para sí mismo como para los demás. Pero los propietarios siempre se tratan como poseedores de todas las opciones de otorgamiento (grant options), por lo que siempre pueden volver a otorgarse sus propios privilegios.

Los privilegios disponibles son:

Los privilegios requeridos por otros comandos se detallan en la página de referencia del comando respectivo.

PostgreSQL otorga privilegios sobre algunos tipos de objetos a PUBLIC de forma predeterminada cuando se crean los objetos. No se otorgan privilegios a PUBLIC por defecto en tablas, columnas de tablas, secuencias, conectores de datos externos, servidores externos, objetos grandes, esquemas, espacios de tablas o parámetros de configuración. Para otros tipos de objetos, los privilegios por defecto otorgados a PUBLIC son los siguientes: privilegios CONNECT y TEMPORARY (crear tablas temporales) para bases de datos; privilegio EXECUTE para funciones y procedimientos; y privilegio USAGE para lenguajes y tipos de datos (incluidos los dominios). El propietario del objeto puede, por supuesto, REVOKE tanto los privilegios por defecto como los otorgados expresamente. (Para una seguridad máxima, ejecuta el REVOKE en la misma transacción que crea el objeto; de este modo no hay ventana de tiempo en la que otro usuario pueda usar el objeto). Además, estas configuraciones de privilegios por defecto pueden ser anuladas utilizando el comando ALTER DEFAULT PRIVILEGES.

La Table 5.1 muestra las abreviaturas de una letra que se utilizan para estos tipos de privilegios en los valores de ACL. Verás estas letras en la salida de los comandos de psql que se enumeran a continuación, o al examinar las columnas de ACL de los catálogos del sistema.

La Table 5.2 resume los privilegios disponibles para cada tipo de objeto SQL, utilizando las abreviaturas mostradas anteriormente. También muestra el comando de psql que se puede utilizar para examinar la configuración de privilegios para cada tipo de objeto.

Los privilegios que se han otorgado para un objeto en particular se muestran como una lista de entradas de tipo aclitem, cada una con el formato:

grantee=privilege-abbreviation[*].../grantor

Cada aclitem enumera todos los permisos de un beneficiario (grantee) que han sido otorgados por un otorgante (grantor) en particular. Los privilegios específicos se representan mediante abreviaturas de una letra de la Table 5.1, con un * añadido si el privilegio se otorgó con la opción de otorgamiento (grant option). Por ejemplo, calvin=r*w/hobbes especifica que el rol calvin tiene el privilegio SELECT (r) con opción de otorgamiento (*), así como el privilegio no otorgable UPDATE (w), ambos otorgados por el rol hobbes. Si calvin también tiene algunos privilegios sobre el mismo objeto otorgados por un otorgante diferente, estos aparecerían como una entrada de aclitem separada. Un campo de beneficiario vacío en un aclitem representa a PUBLIC.

Como ejemplo, supongamos que la usuaria miriam crea la tabla mytable y hace:

GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;

Entonces el comando \dp de psql mostraría:

=> \dp mytable
                                  Access privileges
 Schema |  Name   | Type  |   Access privileges    |   Column privileges   | Policies
--------+---------+-------+------------------------+-----------------------+----------
 public | mytable | table | miriam=arwdDxtm/miriam+| col1:                +|
        |         |       | =r/miriam             +|   miriam_rw=rw/miriam |
        |         |       | admin=arw/miriam       |                       |
(1 row)

Si la columna “Access privileges” está vacía para un objeto dado, significa que el objeto tiene los privilegios por defecto (es decir, su entrada de privilegios en el catálogo del sistema correspondiente es nula). Los privilegios por defecto siempre incluyen todos los privilegios para el propietario, y pueden incluir algunos privilegios para PUBLIC dependiendo del tipo de objeto, como se explicó anteriormente. El primer GRANT o REVOKE sobre un objeto instanciará los privilegios por defecto (produciendo, por ejemplo, miriam=arwdDxt/miriam) y luego los modificará según la solicitud especificada. De manera similar, se muestran entradas en “Column privileges” solo para columnas con privilegios no predeterminados. (Nota: para este propósito, “privilegios por defecto” siempre significa los privilegios por defecto incorporados para el tipo de objeto. Un objeto cuyos privilegios hayan sido afectados por un comando ALTER DEFAULT PRIVILEGES siempre se mostrará con una entrada de privilegios explícita que incluye los efectos del ALTER.)

Ten en cuenta que las opciones de otorgamiento implícitas del propietario no se marcan en la visualización de privilegios de acceso. Solo aparecerá un * cuando las opciones de otorgamiento hayan sido otorgadas explícitamente a alguien.

La columna “Access privileges” muestra (none) cuando la entrada de privilegios del objeto no es nula pero está vacía. Esto significa que no se otorga ningún privilegio en absoluto, ni siquiera al propietario del objeto — una situación inusual. (El propietario todavía tiene opciones de otorgamiento implícitas en este caso, por lo que podría volver a otorgar sus propios privilegios; pero no tiene ninguno en este momento).