CREATE ROLE — Définir un nouveau rôle de base de données
CREATE ROLEnom
[ [ WITH ]option
[ ... ] ] oùoption
peut être : SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | REPLICATION | NOREPLICATION | BYPASSRLS | NOBYPASSRLS | CONNECTION LIMITlimite_connexion
| [ ENCRYPTED ] PASSWORD 'motdepasse
' | PASSWORD NULL | VALID UNTIL 'heuredate
' | IN ROLEnom_role
[, ...] | IN GROUPnom_role
[, ...] | ROLEnom_role
[, ...] | ADMINnom_role
[, ...] | USERnom_role
[, ...] | SYSIDuid
CREATE ROLE
ajoute un nouveau rôle dans une instance
PostgreSQL. Un rôle est une entité qui peut
posséder des objets de la base de données et avoir des droits sur la base
et ses objets. Il peut être considéré comme un « utilisateur »,
un « groupe » ou les deux suivant la façon dont il est utilisé.
Chapitre 22 et Chapitre 21
donnent de plus amples informations sur la gestion des utilisateurs et
l'authentification. Il est nécessaire de posséder le droit
CREATEROLE
ou d'être superutilisateur pour utiliser
cette commande.
Les rôles sont définis au niveau de l'instance, et sont donc disponibles dans toutes les bases de l'instance.
Lors de la création d'un rôle, il est possible d'affecter immédiatement
le nouveau rôle à un rôle existant, et aussi d'affecter des rôles
existants au nouveau rôle. Les règles pour lesquelles les options
d'appartenance de rôle sont activées sont décrites ci-dessous dans les
clauses IN ROLE
, ROLE
et
ADMIN
. La commande GRANT a
un contrôle plus fin lors de l'ajout de membres et la possibilité de
modifier ces options une fois le rôle créé.
nom
Le nom du nouveau rôle.
SUPERUSER
NOSUPERUSER
Ces clauses définissent si le nouveau rôle est un
« superutilisateur » et peut ainsi outrepasser les droits
d'accès à la base de données. Le statut de superutilisateur est
dangereux et ne doit être utilisé qu'en cas d'absolue nécessité. Seul un
superutilisateur peut créer un superutilisateur.
NOSUPERUSER
est la valeur par défaut.
CREATEDB
NOCREATEDB
Ces clauses définissent la capacité d'un rôle à créer des bases de
données. Si CREATEDB
est indiqué, le rôle en cours
de définition sera autorisé à créer de nouvelles bases de données.
Indiquer NOCREATEDB
empêchera un rôle de créer des
bases de données. Si non spécifié, NOCREATEDB
est la
valeur par défaut. Seuls les rôles superutilisateur et les rôles avec
CREATEDB
peuvent spécifier CREATEDB
.
CREATEROLE
NOCREATEROLE
Ces clauses précisent le droit de création, modification, suppression,
ajout de commentaire, et modification du label de sécurité.
Voir création de rôle pour plus de détails sur les
possibilités offertes par ce droit.
NOCREATEROLE
est la valeur
par défaut.
INHERIT
NOINHERIT
Ceci affecte le statut d'héritage des membres quand ce rôle est ajouté
comme membre d'un autre rôle, à la fois dans cette commande et dans les
commandes futures. En particulier, cela contrôle le statut d'héritage des
membres ajoutés avec cette commande en utilisant la clause IN
ROLE
, et dans les commandes ultérieures en utilisant la clause
ROLE
. Cela peut aussi être utilisé en tant que statut
d'héritage par défaut lors de l'ajout de ce rôle comme membre en utilisant
la commande GRANT
. Sans indication,
INHERIT
est le défaut.
Avant PostgreSQL 16, l'héritage était un attribut au niveau rôle, qui contrôlait toutes les vérifications d'appartenance à l'exécution pour ce rôle.
LOGIN
NOLOGIN
Ces clauses précisent si un rôle est autorisé à se connecter,
c'est-à-dire si le rôle peut être donné comme nom pour l'autorisation
initiale de session à la connexion du client. Un rôle ayant l'attribut
LOGIN
peut être vu comme un utilisateur. Les rôles
qui ne disposent pas de cet attribut sont utiles pour gérer les droits
de la base de données mais ne sont pas des utilisateurs au sens habituel
du mot. NOLOGIN
est la valeur par défaut, sauf
lorsque CREATE ROLE
est appelé à travers la commande
CREATE USER
.
REPLICATION
NOREPLICATION
Ces clauses déterminent si un rôle est un rôle de réplication. Un rôle
doit avoir cet attribut (ou être un superutilisateur) pour être capable
de se connecter à un serveur en mode réplication (physique ou logique)
et pour être capable de créer ou supprimer des slots de réplication.
Seuls les rôles superutilisateurs ou les rôles avec l'attribut
REPLICATION
peuvent spécifier
REPLICATION
.
BYPASSRLS
NOBYPASSRLS
Ces clauses déterminent si un rôle contourne toute politique de sécurité
au niveau ligne (RLS). NOBYPASSRLS
est la valeur par
défaut.
Seuls les rôles superutilisateurs ou les rôles avec l'attribut
BYPASSRLS
peuvent spécifier
BYPASSRLS
.
Notez que l'outil pg_dump configure
row_security
à OFF
par défaut pour
s'assurer que tout le contenu d'une table est sauvegardé. Si
l'utilisateur exécutant pg_dump n'a pas les
droits appropriés, une erreur est renvoyée. Néanmoins, les
superutilisateurs et le propriétaire de la table sauvegardée contournent
toujours RLS.
CONNECTION LIMIT
limiteconnexion
Le nombre maximum de connexions concurrentes possibles pour le rôle, s'il possède le droit de connexion. -1 (valeur par défaut) signifie qu'il n'y a pas de limite. Il est à noter que seules les connexions normales sont soumises à cette limite. Les transactions préparées et les connexions des processus worker n'y sont pas soumis.
ENCRYPTED
] PASSWORD
motdepasse
| PASSWORD NULL
Le mot de passe du rôle. Il n'est utile que pour les rôles ayant
l'attribut LOGIN
, mais il est possible d'en définir
un pour les rôles qui ne l'ont pas. Cette option peut être omise si
l'authentification par mot de passe n'est pas envisagée. Si aucun mot de
passe n'est spécifié, le mot de passe est NULL et l'authentification par
mot de passe échouera toujours pour cet utilisateur. Un mot de passe
NULL peut aussi être indiqué explicitement avec PASSWORD
NULL
.
Indiquer un mot de passe vide configurera aussi le mot de passe à NULL, ce qui n'était pas le cas avant la version 10 de PostgreSQL. Dans les versions précédentes, une chaîne vide pouvait être utilisée ou non, suivant la méthode d'authentification et la version exacte, alors que libpq refuserait de l'utiliser dans tous les cas. Pour lever l'ambiguité, une chaîne vide doit être évité.
Le mot de passe est toujours stocké chiffré dans les catalogues système.
Le mot clé ENCRYPTED
n'a aucun effet, mais est accepté
pour compatibilité descendante. La méthode de chiffrement est déterminée
par le paramètre de configuration password_encryption.
Si le texte du mot de passe présenté est chiffré avec un format MD5 ou
SCRAM, alors il sera stocké tel quel sans prendre en compte
password_encryption
(puisque le système ne peut pas
déchiffrer la chaîne du mot de passe spécifiée, pour le chiffrer dans un
format différent). Cela permet de recharger des mots de passe chiffrés
durant une opération de sauvegarde / restauration.
VALID UNTIL
'dateheure
'Cette clause configure la date et l'heure de fin de validité du mot de passe. Sans précision, le mot de passe est indéfiniment valide.
IN ROLE
nom_role
La clause IN ROLE
fait que le nouveau rôle se voit
ajouté automatiquement comme membre des rôles existants cités.
La nouvelle appartenance aura l'option SET
activée et l'option ADMIN
désactivée. L'option
INHERIT
sera activée sauf si l'option
NOINHERIT
est indiquée.
IN GROUP
nom_role
IN GROUP
est un équivalent obsolète de IN
ROLE
.
ROLE
nom_role
La clause ROLE
fait que les rôles existants cités sont
ajoutés automatiquement comme membre du nouveau rôle, avec l'option
SET
activée. Dans les faits, ceci transforme le nouveau
rôle en un « groupe ». Les rôles nommés dans cette clause avec
l'attribut INHERIT
aura l'option
INHERIT
activée dans la nouvelle appartenance. Les
nouveaux membres auront l'option ADMIN
désactivée.
ADMIN
nom_role
Cette clause a le même effet que la clause ROLE
, à la
différence que les rôles nommés sont ajoutés comme membres du nouveau rôle
avec l'option ADMIN
activée. Cela leur confère le droit
de promouvoir à d'autres rôles l'appartenance à celui-ci.
USER
nom_role
USER
est un équivalent obsolète de
ROLE
.
SYSID
uid
La clause SYSID
est ignorée, mais toujours acceptée
pour des raisons de compatibilité.
ALTER ROLE
est utilisé pour modifier les attributs d'un rôle, et DROP ROLE
pour supprimer
un rôle. Tous
les attributs positionnés par CREATE ROLE
peuvent être
modifiés par la suite à l'aide de commandes ALTER ROLE
.
Il est préférable d'utiliser GRANT
et REVOKE
.
pour ajouter et supprimer des membres de rôles utilisés
comme groupe.
La clause VALID UNTIL
définit les date et heure
d'expiration du mot de passe uniquement, pas du rôle. En particulier, les
date et heure d'expiration ne sont pas vérifiées lors de connexions à
l'aide de méthodes d'authentification qui n'utilisent pas les mots de
passe.
Les attributs de rôle définis ici ne sont pas héritables, autrement dit
être membre d'un rôle. Par exemple, CREATEDB
n'autorisera
pas le membre à créer de nouvelles bases y compris si le membre a l'option
INHERIT
. Bien sûr, si l'appartenance a l'option
SET
, le rôle membre serait capable d'utiliser
SET ROLE
vers le
rôle qui a CREATEDB et pourrait ainsi créer une nouvelle base.
Les droits d'appartenance créés par les clauses
IN ROLE
, ROLE
et ADMIN
ont le rôle exécutant cette commande comme donneur.
L'attribut INHERIT
est la valeur par défaut pour des
raisons de compatibilité descendante : dans les précédentes versions
de PostgreSQL, les utilisateurs avaient toujours
accès à tous les droits des groupes dont ils étaient membres. Toutefois,
NOINHERIT
est plus respectueux de la sémantique
spécifiée dans le standard SQL.
PostgreSQL inclut un programme, createuser, qui possède les mêmes fonctionnalités que
CREATE ROLE
(en fait, il appelle cette commande) et peut
être lancé à partir du shell.
L'option CONNECTION LIMIT
n'est vérifiée
qu'approximativement. Si deux nouvelles sessions sont lancées à peu près
simultanément alors qu'il ne reste qu'un seule possibilité de connexion
pour le rôle, il est possible que les deux échouent. De plus, la limite
n'est jamais vérifiée pour les superutilisateurs.
Faites attention lorsque vous donnez un mot de passe non chiffré avec cette
commande. Le mot de passe sera transmis en clair au serveur. Ce dernier
pourrait être tracé dans l'historique des commandes du client ou dans les
traces du serveur. Néanmoins, la commande createuser
transmet le mot de passe chiffré. De plus, psql
contient une commande \password
que vous pouvez utiliser
pour modifier en toute sécurité votre mot de passe.
Créer un rôle qui peut se connecter mais sans lui donner de mot de passe :
CREATE ROLE jonathan LOGIN;
Créer un rôle avec un mot de passe :
CREATE USER davide WITH PASSWORD 'jw8s0F4';
(CREATE USER
est identique à CREATE ROLE
mais
implique l'attribut LOGIN
.)
Créer un rôle avec un mot de passe valide jusqu'à fin 2006. Une seconde après le passage à 2007, le mot de passe n'est plus valide.
CREATE ROLE miriam WITH LOGIN PASSWORD 'jw8s0F4' VALID UNTIL '2007-01-01';
Créer un rôle qui peut créer des bases de données et gérer des rôles :
CREATE ROLE admin WITH CREATEDB CREATEROLE;
L'instruction CREATE ROLE
est définie dans le standard
SQL. Ce dernier n'impose que la syntaxe
CREATE ROLEnom
[ WITH ADMINnom_role
]
La possibilité d'avoir plusieurs superutilisateurs initiaux et toutes les
autres options de CREATE ROLE
sont des extensions
PostgreSQL.
Le standard SQL définit les concepts d'utilisateurs et de rôles mais les considère comme des concepts distincts et laisse la spécification des commandes de définition des utilisateurs à l'implémentation de chaque moteur de bases de données. PostgreSQL a pris le parti d'unifier les utilisateurs et les rôles au sein d'une même entité. Ainsi, les rôles ont plus d'attributs optionnels que dans le standard.
Le comportement spécifié par le standard SQL peut être approché en créant des
utilisateurs du standard SQL comme des rôles
PostgreSQL avec l'option
NOINHERIT
, et les rôles du standard SQL comme des rôles
PostgreSQL avec l'option
INHERIT
.