GRANT — Définir les droits d'accès
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] nom_table [, ...]
| ALL TABLES IN SCHEMA nom_schéma [, ...] }
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( nom_colonne [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( nom_colonne [, ...] ) }
ON [ TABLE ] nom_table [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { { USAGE | SELECT | UPDATE }
[, ...] | ALL [ PRIVILEGES ] }
ON { SEQUENCE nom_séquence [, ...]
| ALL SEQUENCES IN SCHEMA nom_schéma [, ...] }
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
ON DATABASE nom_base [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON DOMAIN nom_domaine [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN DATA WRAPPER nom_fdw [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN SERVER nom_serveur [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { { FUNCTION | PROCEDURE | ROUTINE } nom_routine [ ( [ [ mode_arg ] [ nom_arg ] type_arg [, ...] ] ) ] [, ...]
| ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA nom_schéma [, ...] }
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON LANGUAGE nom_lang [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
ON LARGE OBJECT loid [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { { SET | ALTER SYSTEM } [, ... ] | ALL [ PRIVILEGES ] }
ON PARAMETER paramètre_configuration [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
ON SCHEMA nom_schéma [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE tablespace_name [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
ON TYPE nom_type [, ...]
TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY spécification_rôle ]
GRANT nom_role [, ...] TO spécification_rôle [, ...]
[ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
[ GRANTED BY spécification_rôle ]
où spécification_rôle peut valoir :
[ GROUP ] nom_rôle
| PUBLIC
| CURRENT_ROLE
| CURRENT_USER
| SESSION_USER
La commande GRANT a deux variantes basiques : la première
donne des droits sur un objet de la base de données (table, colonne, vue,
table distante, séquence, base de données, wrapper de données distantes, serveur distant,
fonction, procédure, langage de procédure, « Large Object », paramètre
de configuration, schéma, tablespace ou type), la seconde gère les appartenances à un rôle. Ces variantes sont
assez similaires mais somme toute assez différentes pour être
décrites séparément.
Cette variante de la commande GRANT donne des droits
spécifiques sur un objet de la base de données a un ou plusieurs rôles.
Ces droits sont ajoutés à ceux déjà possédés, s'il y en a.
Le mot clé PUBLIC indique que les droits sont donnés à
tous les rôles, y compris ceux créés ultérieurement.
PUBLIC peut être vu comme un groupe implicitement
défini qui inclut en permanence tous les rôles. Un rôle
particulier dispose de la somme des droits qui lui sont acquis en propre, des droits
de tout rôle dont il est membre et des droits donnés à PUBLIC.
Si WITH GRANT OPTION est précisé, celui qui reçoit le
droit peut le transmettre à son tour (NDT : par la suite on parlera
d'« option de transmission de droit », là où en
anglais il est fait mention de « grant options »).
Sans l'option GRANT, l'utilisateur ne peut pas le faire. Cette option ne
peut pas être donnée à PUBLIC.
Si GRANTED BY est précisé, le donneur indiqué doit être
l'utilisateur courant. Cette clause est actuellement présente dans cette
forme pour la compatibilité SQL.
Il n'est pas nécessaire d'accorder des droits au propriétaire d'un objet (habituellement l'utilisateur qui l'a créé) car, par défaut, le propriétaire possède tous les droits. (Le propriétaire peut toutefois choisir de révoquer certains de ses propres droits.)
Le droit de supprimer un objet ou de modifier sa définition n'est pas configurable avec cette commande. Il est spécifique au propriétaire de l'objet. Ce droit ne peut ni être donné ni supprimé. Néanmoins, il est possible d'avoir le même effet en rendant un utilisateur membre du rôle qui possède cet object ou en le supprimant de ce rôle. Le propriétaire a aussi implicitement les options de transmission de droits pour l'objet.
Les droits possibles sont :
SELECTINSERTUPDATEDELETETRUNCATEREFERENCESTRIGGERCREATECONNECTTEMPORARYEXECUTEUSAGESETALTER SYSTEMTypes spécifiques de droits, comme définis dans Section 5.7.
TEMP
Autre écriture de TEMPORARY.
ALL PRIVILEGES
Donner tous les droits disponibles pour ce type d'objet. Le mot-clé
PRIVILEGES est optionnel dans
PostgreSQL, bien qu'il soit requis en SQL.
La syntaxe FUNCTION fonctionne pour les fonctions
simples, les fonctions d'agrégat, et les fonctions de fenêtrage, mais pas
pour les procédures ; utilisez PROCEDURE pour ces
dernières. Vous pouvez aussi utiliser ROUTINE pour faire
référence à une fonction simple, une fonction d'agrégat, une fonction de
fenêtrage ou une procédure.
Il existe aussi une option pour donner les droits sur tous les objets de
même type dans un ou plusieurs schémas. Cette fonctionnalité est
actuellement supportée par les tables, séquences, fonctions et procédures.
ALL TABLES affecte aussi les vues et les tables
externes, tout comme la commande GRANT de cet objet.
ALL FUNCTIONS affecte aussi les fonctions d'agrégat et
les fonctions de fenêtrage, mais pas les procédures, encore une fois tout
comme la commande GRANT spécifique à l'objet. Utilisez
ALL ROUTINES pour inclure les procédures.
Cette variante de la commande GRANT définit
l'appartenance d'un (ou plusieurs) rôle(s) à un autre et la modification des
options d'appartenance SET, INHERIT et
ADMIN ; voir Section 22.3 pour
les détails. L'appartenance à un rôle est importante parce qu'elle autorise
potentiellement l'accès à des droits donnés par un rôle à chacun de ses
membres, et ainsi que, potentiellement, la capacité de réaliser des
changements au rôle lui-même. Néanmoins, les droits réellement conférés
dépendent des options associées lors du don. Pour modifier les options d'une
appartenance existante, indiquez simplement l'appartenance avec des valeurs
d'option mises à jour.
Chacune des options décrites ci-dessous peut être configurées soit à
TRUE soit à FALSE. Le mot-clé
OPTION est accepté comme synonyme pour
TRUE, donc WITH ADMIN OPTION
est un synonyme pour WITH ADMIN TRUE. Lors de la
modification d'une appartenance existante, l'omission d'une option
résulte en la conservation de la valeur actuelle.
L'option ADMIN autorise le membre à octroyer
l'appartenance à d'autres rôles, et la révoquer. Sans cette option, les
utilisateurs ordinaires ne peuvent pas le faire. Un rôle ne dispose pas de
l'option WITH ADMIN OPTION sur lui-même. Les
superutilisateurs de la base peuvent donner ou révoquer l'appartenance à un
rôle pour toute personne. Cette option est à FALSE par
défaut.
L'option INHERIT contrôle le statut d'héritage du nouveau
membre ; voir Section 22.3 pour les détails sur
l'héritage. Si elle est configurée à TRUE, elle fait que
le nouveau membre hérite du rôle donné. Si elle est configurée à
FALSE, le nouveau membre n'hérite pas. Sans indication
lors de la création d'une nouvelle appartenance de rôle, le défaut est la
valeur de l'attribut d'héritage du nouveau membre.
L'option SET, si elle est configurée à
TRUE, permet au membre de changer vers le rôle donné en
utilisant l'instruction SET
ROLE. Si un rôle est un membre indirect d'un autre rôle, il
peut utiliser SET ROLE seulement s'il existe une chaîne
de dons pour lesquels chacun est configuré à SET TRUE.
Cette option vaut TRUE par défaut.
Pour créer un objet appartenant à un autre rôle ou pour donner la
propriété d'un objet existant à un autre rôle, vous devez avoir la
possibilité d'utiliser SET ROLE sur ce rôle ;
sinon les commandes comme ALTER
... OWNER TO ou CREATE DATABASE ... OWNER
échoueront. Néanmoins, un utilisateur qui hérite des droits d'un rôle
mais n'a pas la capacité d'utiliser SET ROLE vers ce rôle
pourrait être capable d'obtenir les accès complet au rôle en manipulant des
objets existants appartenant à ce rôle (par exemple, ils pourraient
redéfinir une fonction existante pour qu'elle se comportent comme un cheval
de Troie). De ce fait, si les droits d'un rôle peuvent être hérités mais ne
doivent pas être accessibles via SET ROLE, il ne doit pas
être propriétaire d'objets SQL.
Si GRANTED BY est utilisé, l'ajout du droit est enregistré
comme étant fait avec le rôle indiqué. Un utilisateur peut seulement
attribuer un droit à un autre rôle s'ils possèdent les droits de ce rôle.
Le rôle enregistré comme donneur doit avoir ADMIN OPTION
sur le rôle cible, sauf s'il s'agit du superutilisateur initial. Quand un
droit est enregistré comme ayant un donneur autre que le superutilisateur
original, il dépend du donneur qui doit posséder ADMIN
OPTION sur le rôle ; donc, si ADMIN OPTION
est supprimé, les droits dépendants doivent être supprimés en même temps.
Contrairement au cas avec les droits, l'appartenance à un rôle ne peut pas
être donné à PUBLIC. Notez aussi que ce format de la
commande n'autorise pas le mot GROUP dans spécification_rôle.
La commande REVOKE
est utilisée pour retirer les droits d'accès.
Depuis PostgreSQL 8.1, le concept des
utilisateurs et des groupes a été unifié en un seul type d'entité appelé
rôle. Il n'est donc plus nécessaire d'utiliser le mot clé
GROUP pour indiquer si le bénéficiaire est un
utilisateur ou un groupe. GROUP est toujours autorisé
dans cette commande mais est ignoré.
Un utilisateur peut exécuter des SELECT,
INSERT, etc. sur une colonne si il a le privilège soit sur
cette colonne spécifique, soit sur la table entière. Donner un privilège de
table puis le révoquer pour une colonne ne fera pas ce que vous pourriez
espérer : l'autorisation au niveau de la table n'est pas affectée par
une opération au niveau de la colonne.
Quand un utilisateur, non propriétaire d'un objet, essaie d'octroyer des
droits sur cet objet, la commande échoue si l'utilisateur
n'a aucun droit sur l'objet. Tant que des privilèges existent, la commande
s'exécute, mais n'octroie que les droits pour lesquels l'utilisateur dispose
de l'option de transmission.
Les formes GRANT ALL PRIVILEGES engendrent un message d'avertissement
si aucune option de transmission de droit n'est détenue, tandis que les autres formes
n'engendrent un message que lorsque les options de transmission du privilège concerné
par la commande ne sont pas détenues. (Cela s'applique aussi au
propriétaire de l'objet, mais comme on considère toujours que ce dernier détient
toutes les options de transmission, le problème ne se pose jamais.)
Les superutilisateurs de la base de données
peuvent accéder à tous les objets sans tenir compte des droits qui les régissent.
Cela est comparable aux droits de root sur un système
Unix. Comme avec root, il est déconseillé d'opérer en tant que
superutilisateur, sauf en cas d'impérieuse nécessité.
Si un superutilisateur lance une commande GRANT ou
REVOKE, tout se passe comme si la commande était exécutée
par le propriétaire de l'objet concerné. Les droits octroyés par
cette commande semblent ainsi l'avoir été par le propriétaire de l'objet.
(L'appartenance à rôle, elle, semble être donnée par le superutilisateur
original.)
GRANT et REVOKE peuvent aussi être
exécutées par un rôle qui n'est pas le propriétaire de l'objet considéré,
mais est membre du rôle propriétaire de l'objet, ou membre du rôle
titulaire du privilège WITH GRANT OPTION sur cet objet.
Dans ce cas, les droits sont enregistrés comme donnés par le rôle
propriétaire de l'objet ou titulaire du privilège WITH GRANT
OPTION. Par exemple, si la table t1 appartient
au rôle g1, dont le rôle u1 est
membre, alors u1 peut donner les droits sur
t1 à u2, mais ces droits apparaissent
octroyés directement par g1. Tout autre membre du rôle
g1 peut les révoquer par la suite.
Si le rôle qui exécute GRANT détient, de manière indirecte,
les droits souhaités à travers plus d'un niveau d'appartenance, il est difficile
de prévoir le rôle reconnu comme fournisseur du privilège. Dans de tels cas,
le meilleur moyen d'utiliser SET ROLE est de devenir le rôle
qui doit octroyer les droits.
Donner un droit sur une table n'étend pas automatiquement les droits
sur les séquences utilisées par cette table, ceci incluant les
séquences liées par des colonnes de type SERIAL. Les droits
sur les séquences doivent être donnés séparément.
Voir Section 5.7 pour plus d'informations sur les types de droit spécifiques, ainsi que sur la façon d'inspecter les droits sur les objets.
Donner le droit d'insertion à tous les utilisateurs sur la table
films :
GRANT INSERT ON films TO PUBLIC;
Donner tous les droits possibles à l'utilisateur manuel sur la vue
genres :
GRANT ALL PRIVILEGES ON genres TO manuel;
Bien que la commande ci-dessus donne tous les droits lorsqu'elle
est exécutée par un superutilisateur ou par le propriétaire de
genres, exécutée par quelqu'un d'autre, elle
n'accorde que les droits pour lesquels cet utilisateur possède l'option de transmission.
Rendre joe membre de admins :
GRANT admins TO joe;
Conformément au standard SQL, le mot clé PRIVILEGES
est requis dans ALL PRIVILEGES. Le standard SQL
n'autorise pas l'initialisation des droits sur plus d'un objet par commande.
PostgreSQL autorise un propriétaire d'objet
à révoquer ses propres droits ordinaires : par exemple, le
propriétaire d'un objet peut le placer en lecture seule pour lui-même en
révoquant ses propres droits INSERT,
UPDATE, DELETE et
TRUNCATE. Le standard SQL
ne l'autorise pas. La raison en est que
PostgreSQL traite les droits du propriétaire
comme ayant été donnés par le propriétaire ; il peut, de ce fait, aussi les
révoquer. Dans le standard SQL, les droits du propriétaire sont donnés par
une entité « _SYSTEM ». N'étant pas « _SYSTEM », le propriétaire
ne peut pas révoquer ces droits.
D'après le standard SQL, les options de cette commande peuvent être données
à PUBLIC ; PostgreSQL supporte seulement l'ajout des
options de droits aux rôles.
Le standard SQL autorise l'utilisation de l'option GRANTED
BY pour indiquer seulement CURRENT_USER ou
CURRENT_ROLE. Les autres variants sont des extensions de
PostgreSQL.
Le standard SQL fournit un droit USAGE sur d'autres
types d'objet : jeux de caractères, collations, conversions.
Dans le standard SQL, seules les séquences ont un droit USAGE
qui contrôle l'utilisation de l'expression NEXT VALUE FOR,
un équivalent de la fonction nextval dans PostgreSQL.
Les droits SELECT et UPDATE des
séquences sont une extension de PostgreSQL. L'application du droit
USAGE de la séquence à la fonction
currval est aussi une extension PostgreSQL (comme l'est
la fonction elle-même).
Les droits sur les bases de données, tablespaces, schémas, langages et paramètres de configuration sont des extensions PostgreSQL.