GRANT

Descrição

O comando GRANT possui duas funcionalidades básicas: conceder privilégios para um objeto do banco de dados (tabela, visão, seqüência, banco de dados, função, linguagem procedural, esquema e espaço de tabelas), e conceder o privilégio de ser membro de um papel. Estas duas funcionalidades são semelhantes em muitos aspectos, mas são suficientemente diferentes para serem descritas em separado. [1] [2] [3] [4]

A partir do PostgreSQL 8.1 os conceitos de usuário e de grupo foram unificados em um único tipo de entidade chamada de papel. Portanto, não é mais necessário utilizar a palavra chave GROUP para identificar se quem está recebendo a concessão é um usuário ou um grupo. A palavra chave GROUP ainda é permitida neste comando, mas não produz nenhum efeito.

Observações

O comando REVOKE é utilizado para revogar os privilégios de acesso.

Quando alguém que não é o dono do objeto tenta conceder privilégios para o objeto, o comando falha inteiramente caso o usuário não possua ao menos um privilégio para o objeto. Se o usuário possuir algum privilégio para o objeto o comando prosseguirá, mas só concederá os privilégios para os quais o usuário tem a opção de concessão. A forma GRANT ALL PRIVILEGES emite uma mensagem de advertência quando o usuário não possui ao menos uma opção de concessão, enquanto as outras formas emitem uma mensagem de advertência quando o usuário não possui opção de concessão para algum dos privilégios especificamente identificados no comando (Em princípio estas informações também se aplicam ao dono do objeto, mas como o dono é sempre tratado como possuindo todas as opções de concessão estes casos nunca ocorrem).

Deve ser observado que os superusuários do banco de dados podem acessar todos os objetos, independentemente dos privilégios definidos para o objeto. Isto é comparável aos direitos do usuário root no sistema operacional Unix. Assim como no caso do root, não é aconselhável operar como um superusuário a não ser quando for absolutamente necessário.

Se um superusuário decidir submeter o comando GRANT ou REVOKE, o comando será executado como se tivesse sido submetido pelo dono do objeto afetado. Em particular, os privilégio concedidos através deste comando aparecerão como se tivessem sido concedidos pelo dono do objeto (Para o privilégio de membro de um papel irá aparecer como se tivesse sido concedido pelo próprio papel).

As concessões e revogações também podem ser realizadas por um papel que não é o dono do objeto afetado, mas é membro do papel que é dono do objeto, ou é um membro de um papel que possui privilégios com WITH GRANT OPTION no objeto. Nestes casos, os privilégios serão registrados como tendo sido concedidos pelo papel que realmente possui o objeto, ou possui os privilégios com WITH GRANT OPTION. Por exemplo, se a tabela t1 pertencer ao papel g1, do qual o papel u1 é membro, então u1 poderá conceder privilégios sobre t1 para u2, mas estes privilégio aparecerão como se tivessem sido concedidos diretamente por g1. Um outro membro do papel g1 poderá revogar o privilégio posteriormente.

Se o papel que está executando o comando GRANT possuir os privilégios requeridos indiretamente, através de um caminho de membro de mais de um papel, é incerto qual dos papéis será registrado como tendo feito a concessão. Nestes casos, a melhor prática é utilizar o comando SET ROLE para especificar o papel através do qual se deseja fazer a concessão.

Conceder permissão para uma tabela não estende automaticamente a permissão para as seqüências utilizadas pela tabela, inclusive as seqüências ligadas às colunas SERIAL. As permissões para as seqüências devem ser definidas em separado.

Atualmente o PostgreSQL não suporta conceder ou revogar privilégios para as colunas da tabela individualmente. Uma forma possível de contornar esta limitação é criando uma visão contendo apenas as colunas desejadas e, então, conceder os privilégios para a visão.

Pode ser usado o comando \z do aplicativo psql para obter informações sobre os privilégios concedidos como, por exemplo:

=> \z minha_tabela

                       Privilégios de acesso ao banco dados "lusitania"
 Esquema |     Nome     |  Tipo  |                   Privilégios de acesso
---------+--------------+--------+------------------------------------------------------------
 public  | minha_tabela | tabela | {miriam=arwdRxt/miriam,=r/miriam,"group todos=arw/miriam"}
(1 linha)

As entradas mostradas pelo comando \z são interpretadas da seguinte forma:

              =xxxx -- privilégios concedidos para PUBLIC
         uname=xxxx -- privilégios concedidos para o usuário
   group gname=xxxx -- privilégios concedidos para o grupo

                  r -- SELECT ("read")
                  w -- UPDATE ("write")
                  a -- INSERT ("append")
                  d -- DELETE
                  x -- REFERENCES
                  t -- TRIGGER
                  X -- EXECUTE
                  U -- USAGE
                  C -- CREATE
                  c -- CONNECT
                  T -- TEMPORARY
             arwdxt -- ALL PRIVILEGES (para tabelas)
                  * -- opção de concessão para o privilégio precedente

              /yyyy -- usuário que concedeu o privilégio

O exemplo mostrado acima seria visto pela usuária miriam após esta ter criado a tabela minha_tabela e executado:

GRANT SELECT ON minha_tabela TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON minha_tabela TO GROUP todos;

Se a coluna "Access privileges" estiver vazia para um determinado objeto, isto significa que o objeto possui os privilégios padrão (ou seja, sua coluna de privilégios é nula). Os privilégios padrão sempre incluem todos os privilégios para o dono, e podem incluir alguns privilégios para PUBLIC dependendo do tipo do objeto, como foi explicado acima. O primeiro comando GRANT ou REVOKE em um objeto cria uma instância dos privilégios padrão (produzindo, por exemplo, {=,miriam=arwdRxt}) e, em seguida, modifica-os de acordo com a solicitação especificada.

Deve ser observado que as opções de concessão implícitas do dono não são marcadas na visualização dos privilégios de acesso. O * aparece somente quando as opções de concessão foram concedidas explicitamente para alguém.

Exemplos

Conceder, para todos os usuários, o privilégio de inserção na tabela filmes:

GRANT INSERT ON filmes TO PUBLIC;

Conceder ao usuário manuel todos os privilégios disponíveis na visão vis_tipos:

GRANT ALL PRIVILEGES ON vis_tipos TO manuel;

Deve ser observado que, embora o comando acima realmente concederá todos os privilégios se for executado por um superusuário ou pelo dono da visão vis_tipos, se for executado por outra pessoa somente concederá as permissões para as quais esta outra pessoa tiver a opção de conceder o privilégio a terceiros.

Conceder o privilégio de ser membro do papel admins ao usuário joel:

GRANT admins TO joel;

Compatibilidade

De acordo com o padrão SQL, a palavra chave PRIVILEGES em ALL PRIVILEGES é requerida. O padrão SQL não permite definir privilégios para mais de um objeto por comando.

O PostgreSQL permite ao dono do objeto revogar seus próprios privilégios ordinários: por exemplo, o dono da tabela pode tornar a tabela somente de leitura para ele mesmo revogando seus próprios privilégios de INSERT, UPDATE e DELETE. De acordo com o padrão SQL isto não é possível. A razão é que o PostgreSQL trata os privilégios do dono como tendo sido concedidos pelo dono para ele mesmo; portanto ele também pode revogá-los. No padrão SQL os privilégios do dono são concedidos pela entidade assumida "_SYSTEM". Em não sendo o "_SYSTEM", o dono não pode revogar estes direitos.

O padrão SQL permite definir privilégios para as colunas da tabela individualmente:

GRANT privilégios
    ON tabela [ ( coluna [, ...] ) ] [, ...]
    TO { PUBLIC | nome_do_usuário [, ...] } [ WITH GRANT OPTION ]

O padrão SQL estabelece o privilégio USAGE para outros tipos de objeto: conjuntos de caracteres, intercalações (collations [5] [6] [7] [8] ), traduções e domínios.

Os privilégios para bancos de dados, espaços de tabelas e linguagens são extensões do PostgreSQL.

Consulte também

REVOKE