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
| CREATEUSER | NOCREATEUSER
| INHERIT | NOINHERIT
| LOGIN | NOLOGIN
| REPLICATION | NOREPLICATION
| 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 grappe (cluster) de bases de données 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. Il peut être considéré comme un « utilisateur », un « groupe » ou les deux suivant la façon dont il est utilisé. Chapitre 20, Rôles de la base de données et Chapitre 19, 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 la grappe de bases de données, et sont donc valides dans toutes les bases de la grappe.
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é que lorsque cela est réellement nécessaire. 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 produit l'effet inverse. NOCREATEDB est la valeur par défaut.
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, obsolètes mais toujours acceptées, sont équivalentes à SUPERUSER et NOSUPERUSER. Elles ne sont pas équivalentes à CREATEROLE.
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 privilège 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 privilèges 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 peut initier une réplication en flux ou placer le système en mode sauvegarde ou l'en sortir. Un rôle ayant l'attribut REPLICATION est un rôle très privilégié et ne devrait être utilisé que pour la réplication. NOREPLICATION est la valeur par défaut.
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.
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 sera 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.
D'anciens clients peuvent ne pas disposer du support pour le mécanisme d'authentification MD5, nécessaire pour travailler avec les mots de passe stockés chiffrés.
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 qu'administrateur ; 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 osbolè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 groupes.
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 spéciaux 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.
Le privilège 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 superutilisateur). Par exemple, si le rôle « user » 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 le privilège 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 seul « emplacement » de connexion disponible 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 tracer 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 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 administrateurs 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'implantation de chaque base 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.
CREATE OPERATOR FAMILY
