Quando um objeto é criado, é atribuído um dono a ele. Normalmente, o dono do objeto é a função de banco de dados (identificador de autorização/role) que executou o comando de criação. Para a maioria dos tipos de objeto, o estado inicial é de apenas o dono (ou um superusuário) poder fazer alguma coisa com o objeto. Para permitir que outros o usem, devem ser concedidos privilégios.

Existem diferentes tipos de privilégios: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE, SET, ALTER SYSTEM e MAINTAIN. Os privilégios aplicáveis a um determinado objeto variam dependendo do tipo do objeto (tabela, função, etc.). Mais detalhes sobre os significados destes privilégios são mostrados abaixo. As próximas seções e capítulos também mostram como estes privilégios são usados.

O privilégio de modificar ou destruir um objeto é inerente ao dono do objeto, e não pode ser concedido ou revogado. (No entanto, assim como todos os privilégios, esse direito pode ser herdado por membros da função de banco de dados (role) dona do objeto; veja a Seção 21.3.)

Um objeto pode ser atribuído a um novo dono usando o comando ALTER do tipo apropriado para o objeto, como, por exemplo:

ALTER TABLE nome_da_tabela OWNER TO novo_dono;

Os superusuários sempre podem fazer isto; as roles comuns só poderão fazer isto se forem as proprietárias atuais do objeto (ou herdarem os privilégios da role proprietária) e puderem executar SET ROLE para a nova role proprietária.

Para conceder privilégios, é usado o comando GRANT. Por exemplo, se joe for uma role existente e contas for uma tabela existente, o privilégio para atualizar a tabela poderá ser concedido usando:

GRANT UPDATE ON contas TO joe;

Escrever ALL no lugar de um privilégio específico concede todos os privilégios relevantes para o tipo de objeto.

O nome especial de role PUBLIC pode ser usado para conceder um privilégio para todas as roles do sistema. Além disso, podem ser configuradas roles de “grupo” para ajudar a gerenciar privilégios quando houver muitos usuários no banco de dados — para obter mais detalhes, veja o Capítulo 21.

Para revogar um privilégio concedido anteriormente, é usado o comando REVOKE, como no exemplo abaixo:

REVOKE ALL ON contas FROM PUBLIC;

Normalmente, somente o dono do objeto (ou um superusuário) pode conceder ou revogar privilégios para um objeto. Entretanto, é possível conceder um privilégio “com a opção de concessão” (with grant option), que dá a quem recebe o direito de conceder o privilégio para terceiros. Se mais tarde esta opção de concessão for revogada, então todos que receberam o privilégio a partir deste usuário (diretamente, ou por meio de uma cadeia de concessões), perderão este privilégio. Para obter mais detalhes, consulte as páginas de referência dos comandos GRANT e REVOKE.

O dono do objeto pode optar por revogar seus próprios privilégios comuns, como, por exemplo, tornar uma tabela somente de leitura para si e para os outros. Mas os donos são sempre tratados como detentores de todas as opções de concessão, para que sempre possam conceder novamente seus próprios privilégios.

Os privilégios disponíveis são:

Os privilégios exigidos por outros comandos estão listados na página de referência do respectivo comando.

Por padrão, o PostgreSQL concede privilégios para PUBLIC em alguns tipos de objeto, quando estes objetos são criados. Nenhum privilégio é concedido para PUBLIC por padrão em tabelas, colunas de tabela, sequências, empacotadores de dados estrangeiros, servidores estrangeiros, objetos grandes, esquemas, espaços de tabela ou parâmetros de configuração. Para outros tipos de objeto, os privilégios padrão concedidos a PUBLIC são os seguintes: CONNECT e TEMPORARY (criar tabelas temporárias) para bancos de dados; EXECUTE para funções e procedimentos; e USAGE para idiomas e tipos de dados (incluindo domínios). O dono do objeto pode, é claro, revogar (REVOKE) os privilégios padrão e os expressamente concedidos. (Para segurança máxima, deve ser incluído o comando REVOKE na mesma transação que cria o objeto; com isso não haverá uma janela na qual outro usuário possa usar o objeto.) Além disso, estas configurações de privilégio padrão podem ser modificadas usando o comando ALTER DEFAULT PRIVILEGES.

A Tabela 5.1 mostra as abreviaturas de uma letra usadas para esses tipos de privilégio nos valores da ACL (Lista de Controle de Acesso). Estas letras são vistas na saída dos comandos psql listados abaixo ou ao examinar as colunas da ACL dos catálogos do sistema.

A Tabela 5.2 resume os privilégios disponíveis para cada tipo de objeto SQL, usando as abreviaturas mostradas acima. Também mostra o comando do psql que pode ser usado para examinar as configurações de privilégio para cada tipo de objeto.

Os privilégios concedidos para um determinado objeto são exibidos como uma lista de entradas aclitem, cada uma com o seguinte formato:

beneficiário=abreviatura-do-privilégio[*].../outorgante

Cada aclitem lista todas as permissões de um beneficiário que foram concedidas por um outorgante específico. Privilégios específicos são representados por abreviaturas de uma letra da Tabela 5.1, com * apensados se o privilégio foi concedido com a opção de concessão. Por exemplo, calvin=r*w/hobbes especifica que a role calvin possui o privilégio SELECT (r) com opção de concessão (*), assim como o privilégio não concedível UPDATE (w), ambos concedidos pela role hobbes. Se calvin também tiver alguns privilégios neste mesmo objeto concedidos por um outorgante diferente, estes apareceriam como uma entrada aclitem separada. Um campo vazio em um aclitem significa PUBLIC.

Como exemplo, vamos supor que a usuária miriam tenha criado a tabela minha_tabela e executado os seguintes comandos:

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

Então, o comando \dp do psql iria mostrar:

=> \dp minha_tabela
                                    Privilégios de acesso
 Esquema |     Nome     |  Tipo  | Privilégios de acesso  | Privilégios de coluna | Políticas
---------+--------------+--------+------------------------+-----------------------+-----------
 public  | minha_tabela | tabela | miriam=arwdDxtm/miriam+| col1:                +|
         |              |        | =r/miriam             +|   miriam_rw=rw/miriam |
         |              |        | admin=arw/miriam       |                       |
(1 linha)

Se a coluna “Privilégios de acesso” estiver vazia para um determinado objeto, isto significa que o objeto possui os privilégios padrão (ou seja, sua entrada de privilégios no catálogo do sistema relevante é nula). Os privilégios padrão sempre incluem todos os privilégios do dono e podem incluir alguns privilégios para PUBLIC, dependendo do tipo de objeto, conforme explicado acima. O primeiro comando GRANT ou REVOKE em um objeto irá instanciar os privilégios padrão (produzindo, por exemplo, miriam=arwdDxtm/miriam) e então modificá-los conforme a solicitação especificada. Da mesma forma, as entradas são mostradas em “Privilégios de coluna” somente para colunas com privilégios diferentes do padrão (Nota: para este propósito, “privilégios padrão” sempre significa os privilégios padrão nativos para o tipo do objeto. Um objeto cujos privilégios foram afetados por um comando ALTER DEFAULT PRIVILEGES será sempre mostrado como uma entrada de privilégio explícita que inclui os efeitos do comando ALTER).

Note que as opções de concessão implícitas do dono não são marcadas na exibição de privilégios de acesso. Um * aparecerá somente quando as opções de concessão tiverem sido concedidas explicitamente a alguém.

A coluna “Privilégios de acesso” mostra (nenhum) quando a entrada de privilégios do objeto não é nula, mas está vazia. Isto significa que nenhum privilégio foi concedido, nem mesmo para o dono do objeto — uma situação rara. (Neste caso, o dono ainda possui opções de concessão implícitas e, portanto, poderia conceder novamente seus próprios privilégios; porém, no momento, não os possui.)