CREATE ROLE

» » »

Précédent	Niveau supérieur	Suivant
CREATE PUBLICATION	Sommaire	CREATE RULE

CREATE ROLE

CREATE ROLE — Définir un nouveau rôle de base de données

Synopsis

CREATE ROLE nom [ [ WITH ] option [ ... ] ]

où option peut être :

      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE

    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT limite_connexion
    | [ ENCRYPTED ] PASSWORD 'motdepasse' | PASSWORD NULL
    | VALID UNTIL 'heuredate'
    | IN ROLE nom_role [, ...]
    | ROLE nom_role [, ...]
    | ADMIN nom_role [, ...]
    | SYSID uid

Description

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 21 et Chapitre 20 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éé.

Paramètres

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.

Note

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.

Avertissement

L'utilisation de mots de passe hachés avec MD5 est considérée comme obsolète et sera supprimée d'une version future de PostgreSQL. Référez-vous à Section 20.5 pour les détails sur la migration vers un autre type de chiffrement de mot de passe.

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.

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.

SYSID uid

La clause SYSID est ignorée, mais toujours acceptée pour des raisons de compatibilité.

Notes

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.

Exemples

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;

Compatibilité

L'instruction CREATE ROLE est définie dans le standard SQL. Ce dernier n'impose que la syntaxe

CREATE ROLE nom [ WITH ADMIN nom_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.

La clause USER a le même comportement que ROLE mais est obsolète :

USER nom_role [, ...]

La clause IN GROUP a le même comportement que IN ROLE mais est obsolète :

IN GROUP nom_role [, ...]

Voir aussi

SET ROLE, ALTER ROLE, DROP ROLE, GRANT, REVOKE, createuser, createrole_self_grant