GRANT — define privilégios de acesso
GRANT { { SELECT
| INSERT
| UPDATE
| DELETE
| TRUNCATE
| REFERENCES
| TRIGGER
| MAINTAIN
}
[, ...]
| ALL [ PRIVILEGES ]
}
ON { [ TABLE ] nome_da_tabela [, ...]
| ALL TABLES IN SCHEMA nome_do_esquema [, ...]
}
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { { SELECT
| INSERT
| UPDATE
| REFERENCES
}
( nome_da_coluna [, ...] )
[, ...]
| ALL [ PRIVILEGES ] ( nome_da_coluna [, ...] )
}
ON [ TABLE ] nome_da_tabela [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { { USAGE
| SELECT
| UPDATE
}
[, ...]
| ALL [ PRIVILEGES ]
}
ON { SEQUENCE nome_da_sequência [, ...]
| ALL SEQUENCES IN SCHEMA nome_do_esquema [, ...]
}
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { { CREATE
| CONNECT
| TEMPORARY
| TEMP
}
[, ...]
| ALL [ PRIVILEGES ]
}
ON DATABASE nome_do_banco_de_dados [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON DOMAIN nome_do_domínio [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN DATA WRAPPER nome_do_empacotador [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN SERVER nome_do_servidor [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { { FUNCTION
| PROCEDURE
| ROUTINE
}
nome_da_rotina
[ ( [ [ modo_do_argumento ]
[ nome_do_argumento ]
tipo_de_dados_do_argumento
[, ...]
]
) ]
[, ...]
| ALL { FUNCTIONS
| PROCEDURES
| ROUTINES
}
IN SCHEMA nome_do_esquema [, ...]
}
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON LANGUAGE nome_da_linguagem [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
ON LARGE OBJECT loid [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { { SET | ALTER SYSTEM } [, ... ] | ALL [ PRIVILEGES ] }
ON PARAMETER parâmetro_de_configuração [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
ON SCHEMA nome_do_esquema [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE nome_do_espaço_de_tabelas [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON TYPE nome_do_tipo_de_dados [, ...]
TO especificação_da_role [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY especificação_da_role ]
GRANT nome_da_role [, ...] TO especificação_da_role [, ...]
[ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
[ GRANTED BY especificação_da_role ]
onde especificação_da_role pode ser:
[ GROUP ] nome_da_role
| PUBLIC
| CURRENT_ROLE
| CURRENT_USER
| SESSION_USER
O comando GRANT possui duas variantes básicas:
uma que concede privilégios a um objeto de banco de dados
(tabela, coluna, visão, tabela estrangeira, sequência, banco de dados,
empacotador de dados externos, servidor externo, função, procedimento,
linguagem procedural, objeto grande, parâmetro de configuração,
esquema, espaço de tabelas ou tipo de dados),
e outra que concede a participação em uma função de banco de dados
(role).
Estas variantes são semelhantes em muitos aspectos, mas são
suficientemente diferentes para serem descritas separadamente.
GRANT em objetos de banco de dados
Esta variante do comando GRANT concede privilégios
específicos em um objeto de banco de dados a uma ou mais
funções de banco de dados (roles).
Estes privilégios são adicionados aos já concedidos, se houver.
A palavra-chave PUBLIC indica que os privilégios
devem ser concedidos a todas as funções de banco de dados,
incluindo aquelas que possam ser criadas posteriormente.
PUBLIC pode ser considerado como sendo um grupo
implicitamente definido que sempre inclui todas as
funções de banco de dados.
Qualquer função de banco de dados específica terá a soma dos
privilégios concedidos diretamente a ela, dos privilégios concedidos
a qualquer função de banco de dados da qual ela seja atualmente
membro e dos privilégios concedidos a PUBLIC.
Se for especificado WITH GRANT OPTION, o
beneficiário do privilégio poderá, por sua vez, concedê-lo a outros.
Sem a opção de concessão, o beneficiário não pode fazer isto.
As opções de concessão não podem ser concedidas a
PUBLIC.
Se for especificado GRANTED BY, o concessor
especificado deve ser o usuário corrente.
Esta cláusula está presente neste formato apenas para fins de
compatibilidade com o padrão SQL.
Não há necessidade de conceder privilégios ao dono de um objeto (geralmente o usuário que o criou), porque o dono possui todos os privilégios por padrão. (O dono poderá, no entanto, optar por revogar alguns de seus próprios privilégios por motivos de segurança.)
O direito de excluir um objeto, ou de alterar sua definição de qualquer forma, não é tratado como um privilégio concedível; é inerente ao dono e não pode ser concedido nem revogado. (Entretanto, um efeito semelhante pode ser obtido concedendo ou revogando a participação na função de banco de dados que possui o objeto; veja abaixo.) O dono também possui implicitamente todas as opções de concessão para o objeto.
Os privilégios possíveis são:
SELECTINSERTUPDATEDELETETRUNCATEREFERENCESTRIGGERCREATECONNECTTEMPORARYEXECUTEUSAGESETALTER SYSTEMMAINTAINTipos específicos de privilégios, conforme definidos em Privilégios.
TEMP
Grafia alternativa para TEMPORARY.
ALL PRIVILEGES
Concede todos os privilégios disponíveis para o tipo de objeto.
A palavra-chave PRIVILEGES é opcional no
PostgreSQL, embora seja requerida no
SQL estrito.
A sintaxe FUNCTION funciona para funções simples,
funções de agregação e funções de janela, mas não para procedimentos;
deve ser usado PROCEDURE para estes.
Como alternativa, pode ser usado ROUTINE para se
referir a uma função, função de agregação, função de janela ou
procedimento, independentemente de seu tipo preciso.
Existe também a opção de conceder privilégios a todos os objetos
do mesmo tipo dentro de um ou mais esquemas.
Esta funcionalidade tem suporte atualmente apenas para tabelas,
sequências, funções e procedimentos.
ALL TABLES também afeta visões e tabelas
estrangeiras, da mesma forma que o comando GRANT
para um objeto específico faz.
ALL FUNCTIONS também afeta funções de agregação
e de janela, mas não procedimentos, da mesma forma que o comando
GRANT para um objeto específico faz.
Deve ser usado ALL ROUTINES para incluir os
procedimentos.
GRANT em funções de banco de dados (roles)
Esta variante do comando GRANT concede a
participação em uma função de banco de dados a uma ou mais outras
funções de banco de dados, e a modificação das opções de participação
SET, INHERIT e
ADMIN;
veja Seção 21.3 para obter detalhes.
A participação em uma função de banco de dados é importante, porque
permite potencialmente o acesso aos privilégios concedidos a esta
função de banco de dados a cada um de seus membros, e também a
possibilidade de fazer alterações na própria função de banco de dados.
Entretanto, as permissões efetivamente concedidas dependem das
opções associadas à concessão.
Para modificar as opções de uma participação existente, basta
especificar a participação com os valores de opção atualizados.
Cada uma das opções descritas abaixo pode ser definida como
TRUE ou FALSE.
A palavra-chave OPTION é aceita como sinônimo de
TRUE, assim sendo WITH ADMIN OPTION
é sinônimo de WITH ADMIN TRUE.
Ao alterar uma participação existente, a omissão de uma opção resulta
na manutenção do valor corrente.
A opção ADMIN permite que o membro, por sua vez,
conceda acesso à função de banco de dados a outros e revogue este
acesso também.
Sem a opção de administrador, os usuários comuns não podem fazer isto.
Uma função de banco de dados não é considerada como tendo
WITH ADMIN OPTION sobre si mesma.
Os superusuários do banco de dados podem conceder ou revogar a
participação em qualquer função de banco de dados para qualquer pessoa.
Esta opção tem como valor padrão FALSE.
A opção INHERIT controla o status de herança do
novo membro; veja Seção 21.3
para obter detalhes sobre herança.
Se estiver definido como TRUE, fará com que
o novo membro herde da função de banco de dados concedida.
Se definido como FALSE, o novo membro não herdará.
Caso não seja especificado ao criar uma nova participação em uma
função de banco de dados, o valor padrão será o atributo de
herança do novo membro.
A opção SET, se estiver definida como
TRUE, permitirá que o membro alterne para a
função de banco de dados concedida usando o comando
SET ROLE.
Se uma função de banco de dados for membro indireto de outra
função de banco de dados, só poderá usar SET ROLE
para alternar para esta função de banco de dados se houver uma cadeia
de concessões, cada uma das quais possuindo SET TRUE.
Esta opção tem como valor padrão TRUE.
Para criar um objeto pertencente a outra função de banco de dados,
ou atribuir a posse de um objeto existente a outra
função de banco de dados, é necessário ser capaz de executar
SET ROLE para esta função de banco de dados;
caso contrário, comandos como ALTER ... OWNER TO
ou CREATE DATABASE ... OWNER irão falhar.
Entretanto, um usuário que herda os privilégios de uma
função de banco de dados, mas não possui a capacidade de executar
SET ROLE para esta função de banco de dados,
pode obter acesso total esta função de banco de dados manipulando
objetos existentes pertencentes a esta função de banco de dados
(por exemplo, redefinindo uma função existente para atuar
como um Cavalo de Troia).
Portanto, se os privilégios de uma função de banco de dados devem
ser herdados, mas não devem ser acessíveis por meio de
SET ROLE, ela não deverá possuir nenhum objeto
SQL.
Se for especificado GRANTED BY, a concessão será
registrada como tendo sido feita pela função de banco de dados
especificada.
Um usuário só poderá atribuir uma permissão a outra função de banco
de dados se possuir os privilégios dessa função de banco de dados.
A função registrada como concessora deve possuir
ADMIN OPTION na função de banco de dados
de destino, a menos que seja o superusuário de inicialização
(bootstrap).
Quando uma concessão é registrada como tendo um concessor diferente
do superusuário de inicialização, isto dependerá do concessor
continuar possuindo ADMIN OPTION na
função de banco de dados; portanto, se ADMIN OPTION
for revogada, as concessões dependentes também deverão ser revogadas.
Ao contrário do que acontece com os privilégios, a participação
em uma função de banco de dados não pode ser concedida a
PUBLIC.
Note também que esta forma de comando não permite a palavra ruído
GROUP na
especificação_da_role.
É usado o comando REVOKE para revogar privilégios de acesso.
Desde o PostgreSQL 8.1, os conceitos
de usuários e grupos foram unificados em um único tipo de entidade
chamada função de banco de dados (role).
Portanto, não é mais necessário usar a palavra-chave
GROUP para identificar se um beneficiário
é um usuário ou um grupo.
A cláusula GROUP ainda é permitida no comando,
mas é uma palavra ruído.
O usuário pode executar SELECT,
INSERT, etc., em uma coluna se tiver este
privilégio para a coluna específica, ou para toda a tabela.
Conceder o privilégio no nível da tabela e revogá-lo para uma
coluna não fará o que se deseja: a concessão no nível de tabela
não é afetada por uma operação no nível de coluna.
Quando um não-dono de um objeto tenta conceder privilégios no objeto,
o comando irá falhar totalmente se o usuário não tiver nenhum
privilégio no objeto.
Enquanto algum privilégio estiver disponível, o comando continuará,
mas concederá apenas os privilégios para os quais o usuário tem
opção de concessão.
As formas de GRANT ALL PRIVILEGES emitem uma
mensagem de advertência se nenhuma opção de concessão estiver presente,
enquanto as outras formas emitem uma advertência se as opções de
concessão, para qualquer um dos privilégios especificamente
indicados no comando, não estiverem presentes.
(Em princípio, estas afirmações também se aplicam ao dono do objeto,
mas como o dono é sempre tratado como detentor de todas as opções
de concessão, os casos nunca podem ocorrer.)
Deve-se notar que os superusuários do banco de dados podem acessar
todos os objetos, independentemente das configurações de privilégio
do objeto.
É comparável aos direitos do usuário root em um
sistema Unix.
Assim como o root, não é aconselhável operar
como superusuário, exceto quando é absolutamente necessário.
Se um superusuário escolher executar o comando
GRANT ou REVOKE, o comando
será executado como se tivesse sido executado pelo dono do objeto
afetado.
Em particular, os privilégios concedidos por meio desse comando vão
parecer ter sido concedidos pelo dono do objeto.
(Para se tornar membro dessa função de banco de dados, a participação
parece ter sido concedida pelo superusuário de inicialização.)
Os comandos GRANT e REVOKE
também podem ser executados por uma função que não é a dona do
objeto afetado, mas é membro de uma função de banco de dados
(role) que é dona do objeto,
ou é membro de uma função de banco de dados que possui o
privilégio WITH GRANT OPTION no objeto.
Neste caso, os privilégios serão registrados como concedidos pela
função de banco de dados que realmente é dona do objeto, ou detém
o privilégio WITH GRANT OPTION.
Por exemplo, se a tabela t1 pertencer à
função de banco de dados g1,
da qual a função u1 é membro,
então u1 pode conceder privilégios em
t1 para u2,
mas estes privilégios parecerão ter sido concedidos diretamente
por g1.
Qualquer outro membro da função de banco de dados
g1 poderá revogá-los posteriormente.
Se a função de banco de dados que executa o comando
GRANT detiver os privilégios necessários
indiretamente, por meio de mais de um caminho para se tornar membro
da função de banco de dados, não será especificada qual
função de banco de dados contendo o privilégio será registrada
como tendo feito a concessão.
Nesses casos, é uma prática recomendada usar o comando
SET ROLE para se tornar a função de banco de
dados específica pela qual se deseja executar o comando
GRANT.
A concessão de permissão em uma tabela não estende automaticamente
as permissões para quaisquer sequências usadas pela tabela,
incluindo sequências SERIAL vinculadas a colunas.
As permissões nas sequências devem ser concedidas separadamente.
Veja Privilégios para obter mais informações sobre tipos específicos de privilégios, bem como sobre como inspecionar os privilégios dos objetos.
Conceder o privilégio de inserção na tabela films
a todos os usuários:
GRANT INSERT ON films TO PUBLIC;
Conceder todos os privilégios disponíveis na visão
kinds ao usuário manuel:
GRANT ALL PRIVILEGES ON kinds TO manuel;
Note que, embora o que foi feito acima conceda de fato todos os
privilégios se executado por um superusuário, ou pelo dono da visão
kinds, quando executado por outro usuário
concederá apenas as permissões para as quais o outro usuário tem
opção de concessão.
Conceder ser membro da função de banco de dados
admins ao usuário joe:
GRANT admins TO joe;
Segundo o padrão SQL, é necessária a palavra-chave
PRIVILEGES em ALL PRIVILEGES.
O padrão SQL não oferece suporte à definição
de privilégios em mais de um objeto por comando.
O PostgreSQL permite que o dono de objeto
revogue seus próprios privilégios comuns: por exemplo, o dono da
tabela pode tornar a tabela de leitura-apenas revogando seus próprios
privilégios INSERT, UPDATE,
DELETE, e TRUNCATE.
Isto não é possível segundo o padrão SQL.
A razão é que o PostgreSQL trata os
privilégios do dono como tendo sido concedidos pelo dono a si mesmo;
portanto, eles também podem 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 privilégios.
Segundo o padrão SQL, as opções de concessão
podem ser concedidas a PUBLIC;
O PostgreSQL oferece suporte apenas à
concessão de opção de concessão a funções de banco de dados
(roles).
O padrão SQL permite que a opção
GRANTED BY especifique apenas
CURRENT_USER ou CURRENT_ROLE.
As outras variantes são extensões do
PostgreSQL.
O padrão SQL aceita o privilégio
USAGE em outros tipos de objetos:
conjuntos de caracteres, ordenações, traduções.
No padrão SQL, as sequências permitem apenas o
privilégio USAGE, que controla o uso da expressão
NEXT VALUE FOR, que é equivalente à função
nextval no PostgreSQL.
Os privilégios de sequência SELECT e
UPDATE são extensões do
PostgreSQL.
A aplicação do privilégio USAGE da sequência
à função currval também é uma extensão do
PostgreSQL
(assim como é a própria função).
Privilégios em bancos de dados, espaços de tabelas, esquemas, linguagens e parâmetros de configuração são extensões do PostgreSQL.