| > > > | |
 CREATE POLICY
|
CREATE RULE
|
CREATE ROLE — Définir un nouveau rôle de base de données
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 | UNENCRYPTED ] PASSWORD 'motdepasse'
| VALID UNTIL 'heuredate'
| IN ROLE nom_role [, ...]
| IN GROUP nom_role [, ...]
| ROLE nom_role [, ...]
| ADMIN nom_role [, ...]
| USER nom_role [, ...]
| SYSID uid
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, Rôles de la base de données et Chapitre 20, Authentification du client 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.
Le nom du nouveau rôle.
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.
Ces clauses précisent le droit de création de bases de données. Si CREATEDB est spécifié, l'autorisation est donnée au rôle. NOCREATEDB, valeur par défaut, produit l'effet inverse.
Ces clauses précisent le droit de création de nouveaux rôles (c'est-à-dire d'exécuter CREATE ROLE). Un rôle qui possède le droit CREATEROLE peut aussi modifier ou supprimer d'autres rôles. NOCREATEROLE est la valeur par défaut.
Ces clauses précisent si un rôle « hérite » des droits d'un rôle dont il est membre. Un rôle qui possède l'attribut INHERIT peut automatiquement utiliser tout droit détenu par un rôle dont il est membre direct ou indirect. Sans INHERIT, l'appartenance à un autre rôle lui confère uniquement la possibilité d'utiliser SET ROLE pour acquérir les droits de l'autre rôle ; ils ne sont disponibles qu'après cela. INHERIT est la valeur par défaut.
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(7).
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. Vous devez être superutilisateur pour créer un nouveau rôle ayant l'attribut REPLICATION.
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. Vous devez être superutilisateur pour créer un nouveau rôle ayant l'attribut 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.
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.
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.
Ces mots clés contrôlent le chiffrement du mot de passe stocké dans les catalogues système. En l'absence de précision, le comportement par défaut est déterminé par le paramètre de configuration password_encryption. Si le mot de passe présenté est déjà une chaîne chiffrée avec MD5, il est stocké ainsi, quelque soit le mot-clé spécifié, ENCRYPTED ou UNENCRYPTED (le système ne peut pas déchiffrer la chaîne déjà chiffrée). Cela permet de recharger des mots de passe chiffrés lors d'opérations de sauvegarde/restauration.
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.
Cette clause liste les rôles dont le nouveau rôle est membre. Il n'existe pas d'option pour ajouter le nouveau rôle en tant que superutilisateur ; cela se fait à l'aide d'une commande GRANT séparée.
IN GROUP est un équivalent obsolète de IN ROLE.
Cette clause liste les rôles membres du nouveau rôle. Le nouveau rôle devient ainsi un « groupe ».
Cette clause est équivalente à la clause ROLE, à la différence que les rôles nommés sont ajoutés au nouveau rôle avec l'option WITH ADMIN OPTION. Cela leur confère le droit de promouvoir à d'autres rôles l'appartenance à celui-ci.
USER est un équivalent obsolète de ROLE.
La clause SYSID est ignorée, mais toujours acceptée pour des raisons de compatibilité.
ALTER ROLE(7) est utilisé pour modifier les attributs d'un rôle, et DROP ROLE(7) 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(7) et REVOKE(7) 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.
L'attribut INHERIT gouverne l'héritage des droits conférables (c'est-à-dire les droits d'accès aux objets de la base de données et les appartenances aux rôles). Il ne s'applique pas aux attributs de rôle configurés par CREATE ROLE et ALTER ROLE. Par exemple, être membre d'un rôle disposant du droit CREATEDB ne confère pas automatiquement le droit de création de bases de données, même avec INHERIT positionné ; il est nécessaire d'acquérir ce rôle via SET ROLE(7) avant de créer une base de données.
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.
L'attribut CREATEROLE impose quelques précautions. Il n'y a pas de concept d'héritage des droits pour un tel rôle. Cela signifie qu'un rôle qui ne possède pas un droit spécifique, mais est autorisé à créer d'autres rôles, peut aisément créer un rôle possédant des droits différents des siens (sauf en ce qui concerne la création des rôles superutilisateurs). Par exemple, si le rôle « u1 » a le droit CREATEROLE mais pas le droit CREATEDB, il peut toujours créer un rôle possédant le droit CREATEDB. Il est de ce fait important de considérer les rôles possédant l'attribut CREATEROLE comme des superutilisateurs en puissance.
PostgreSQL™ inclut un programme, createuser(1), 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(1) transmet le mot de passe chiffré. De plus, psql(1) 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 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 donnant aux utilisateurs l'attribut NOINHERIT et aux rôles l'attribut INHERIT.