CREATE ROLE |
Crée un rôle |
|---|---|
| PostgreSQL | |
Syntaxe
|
CREATE ROLE name [ [ WITH ] option [ ... ] ] où option peut être : SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | REPLICATION | NOREPLICATION | BYPASSRLS | NOBYPASSRLS | CONNECTION LIMIT connlimit | [ ENCRYPTED ] PASSWORD 'password' | VALID UNTIL 'timestamp' | IN ROLE role_name [, ...] | IN GROUP role_name [, ...] | ROLE role_name [, ...] | ADMIN role_name [, ...] | USER role_name [, ...] | SYSID uid |
Paramètres
| Nom | Description |
|---|---|
| name | Ce paramètre permet d'indiquer le nom du nouveau rôle. |
| SUPERUSER | Ce paramètre permet de déterminer si le nouveau rôle est un «superutilisateur», pouvant outrepasser toutes les restrictions d'accès au sein de la base de données. L'état de superutilisateur est dangereux et ne doit être utilisé que lorsque cela est vraiment nécessaire. Vous devez être vous-même un superutilisateur pour créer un nouveau superutilisateur. S'il n'est pas spécifié, NOSUPERUSER est la valeur par défaut. |
| NOSUPERUSER | Ce paramètre permet d'indiquer qu'il ne s'agit pas d'un superutilisateur. |
| CREATEDB | Ce paramètre permet de définir la capacité d'un rôle à créer des bases de données. Si CREATEDB est spécifié, le rôle en cours de définition sera autorisé à créer de nouvelles bases de données. |
| NOCREATEDB | Ce paramètre permet d'indiquer qu'il refusera à un rôle la possibilité de créer des bases de données. S'il n'est pas spécifié, NOCREATEDB est la valeur par défaut. |
| CREATEROLE | Ce paramètre permet d'indiquer qu'un rôle sera autorisé à créer de nouveaux rôles (c'est-à-dire à exécuter CREATE ROLE). Un rôle avec le privilège CREATEROLE peut également modifier et supprimer d'autres rôles. |
| NOCREATEROLE | Ce paramètre permet d'indiquer qu'il n'est pas autorisé à créer de nouveau rôle. S'il n'est pas spécifié, NOCREATEROLE est la valeur par défaut. |
| INHERIT | Ce paramètre permet d'indiquer qu'un rôle «hérite» des privilèges des rôles dont il est membre. Un rôle avec l'attribut INHERIT peut utiliser automatiquement les privilèges de base de données accordés à tous les rôles dont il est directement ou indirectement membre. Sans INHERIT, l'appartenance à un autre rôle accorde uniquement la possibilité de SET ROLE à cet autre rôle ; les privilèges de l'autre rôle ne sont disponibles qu'après l'avoir fait. S'il n'est pas spécifié, INHERIT est la valeur par défaut. |
| NOINHERIT | Ce paramètre permet d'indiquer que le rôle n'est pas hérités. |
| LOGIN | Ce paramètre permet d'indiquer qu'un rôle est autorisé à se connecter ; c'est-à-dire si le rôle peut être attribué comme nom d'autorisation de session initial lors de la connexion client. Un rôle ayant l'attribut LOGIN peut être considéré comme un utilisateur. Les rôles sans 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 terme. S'il n'est pas spécifié, NOLOGIN est la valeur par défaut, sauf lorsque CREATE ROLE est invoqué via son orthographe alternative CREATE USER. |
| NOLOGIN | Ce paramètre permet d'indiquer qu'un rôle n'est pas autorisé à se connecter. |
| REPLICATION | Ce paramètre permet d'indiquer le rôle est un rôle de réplication. Un rôle doit avoir cet attribut (ou être un superutilisateur) pour pouvoir se connecter au serveur en mode de réplication (réplication physique ou logique) et pour pouvoir créer ou supprimer des slots de réplication. Un rôle ayant l'attribut REPLICATION est un rôle hautement privilégié et ne doit être utilisé que sur des rôles réellement utilisés pour la réplication. S'il n'est pas spécifié, NOREPLICATION est la valeur par défaut. Vous devez être un superutilisateur pour créer un nouveau rôle ayant l'attribut REPLICATION. |
| NOREPLICATION | Ce paramètre permet d'indiquer que le rôle n'est pas un rôle de réplication. |
| BYPASSRLS | Ce paramètre permet de déterminer si un rôle contourne chaque stratégie de sécurité au niveau des lignes (RLS). Vous devez être un superutilisateur pour créer un nouveau rôle ayant l'attribut BYPASSRLS. Notez que pg_dump définira row_security sur OFF par défaut, pour s'assurer que tout le contenu d'une table est vidé. Si l'utilisateur exécutant pg_dump n'a pas les autorisations appropriées, une erreur sera renvoyée. Cependant, les superutilisateurs et le propriétaire de la table en cours de vidage contournent toujours RLS. |
| NOBYPASSRLS | Ce paramètre permet d'indiquer que le rôle ne contournera pas chaque stratégie de sécurité au niveau des lignes (RLS). Le paramètre NOBYPASSRLS est la valeur par défaut. |
| CONNECTION LIMIT connlimit | Ce paramètre permet d'indiquer la limite de connexion. Si le rôle peut se connecter, cela spécifie le nombre de connexions simultanées que le rôle peut établir. -1 (la valeur par défaut) signifie aucune limite. Notez que seules les connexions normales sont prises en compte dans cette limite. Ni les transactions préparées ni les connexions de travail en arrière-plan ne sont prises en compte dans cette limite. |
| [ ENCRYPTED ] PASSWORD password | Ce paramètre permet de définir le mot de passe du rôle. (Un mot de passe n'est utile que pour les rôles ayant l'attribut LOGIN, mais vous pouvez néanmoins en définir un pour les rôles sans celui-ci.) Si vous ne prévoyez pas d'utiliser l'authentification par mot de passe, vous pouvez omettre cette option. Si aucun mot de passe n'est spécifié, le mot de passe sera défini sur null et l'authentification par mot de passe échouera toujours pour cet utilisateur. Un mot de passe nul peut éventuellement être écrit explicitement sous la forme PASSWORD NULL. Spécifier une chaîne de caractères vide mettra également le mot de passe à null, mais ce n'était pas le cas avant la version 10 de PostgreSQL. Dans les versions antérieures, une chaîne vide pouvait être utilisée, ou non, selon la méthode d'authentification et la version exacte, et libpq le ferait refuser de l'utiliser dans tous les cas. Pour éviter l'ambiguïté, il faut éviter de spécifier une chaîne de caractères vide. Le mot de passe est toujours entreposé crypté dans les catalogues système. Le mot clef ENCRYPTED n'a aucun effet, mais est accepté pour la compatibilité descendante. La méthode de cryptage est déterminée par le paramètre de configuration password_encryption. Si la chaîne de caractères de mot de passe présentée est déjà au format crypté MD5 ou SCRAM, elle est entreposée telle quelle indépendamment de password_encryption (puisque le système ne peut pas déchiffrer la chaîne de caractères de mot de passe cryptée spécifiée, pour la crypter dans un format différent). Cela permet de recharger les mots de passe cryptés pendant le vidage/restauration. |
| VALID UNTIL 'timestamp' | Ce paramètre permet de définir une date et une heure après lesquelles le mot de passe du rôle n'est plus valide. Si cette clause est omise, le mot de passe sera valable pour toujours. |
| IN ROLE role_name | Ce paramètre permet de répertorier un ou plusieurs rôles existants auxquels le nouveau rôle sera immédiatement ajouté en tant que nouveau membre. (Notez qu'il n'y a pas d'option pour ajouter le nouveau rôle en tant qu'administrateur ; utilisez une commande GRANT distincte pour le faire.) |
| IN GROUP role_name | Ce paramètre permet d'indiquer une orthographe obsolète de IN ROLE. |
| ROLE role_name | Ce paramètre permet de répertorier un ou plusieurs rôles existants étant automatiquement ajoutés en tant que membres du nouveau rôle. (Ceci fait du nouveau rôle un «group».) |
| ADMIN role_name | Ce paramètre est similaire à ROLE, mais les rôles nommés sont ajoutés au nouveau rôle WITH ADMIN OPTION, ce qui leur donne le droit d'accorder l'appartenance à ce rôle à d'autres. |
| USER role_name | Ce paramètre permet d'indiquer une orthographe obsolète de la clause ROLE. |
| SYSID uid | Ce paramètre permet d'indiquer l'identificateur système. La clause SYSID est ignorée, mais est acceptée pour la compatibilité descendante. |
Description
Cette instruction permet de définir un nouveau rôle de base de données.
Remarques
- Utilisez ALTER ROLE pour modifier les attributs d'un rôle et DROP ROLE pour supprimer un rôle. Tous les attributs spécifiés par CREATE ROLE peuvent être modifiés par des commandes ALTER ROLE ultérieures.
- La meilleure façon d'ajouter et de supprimer des membres de rôles étant utilisés en tant que groupes consiste à utiliser GRANT et REVOKE.
- La clause VALID UNTIL définit un délai d'expiration pour un mot de passe uniquement, pas pour le rôle en soi. En particulier, le délai d'expiration n'est pas appliqué lors de la connexion à l'aide d'une méthode d'authentification sans mot de passe.
- L'attribut INHERIT régit l'héritage des privilèges pouvant être accordés (c'est-à-dire les privilèges d'accès pour les objets de base de données et les appartenances aux rôles). Il ne s'applique pas aux attributs de rôle spéciaux définis par CREATE ROLE et ALTER ROLE. Par exemple, être membre d'un rôle avec le privilège CREATEDB n'accorde pas immédiatement la possibilité de créer des bases de données, même si INHERIT est défini ; il serait nécessaire de devenir ce rôle via SET ROLE avant de créer une base de données.
- L'attribut INHERIT est la valeur par défaut pour des raisons de rétrocompatibilité : dans les versions précédentes de PostgreSQL, les utilisateurs avaient toujours accès à tous les privilèges des groupes dont ils étaient membres. Cependant, NOINHERIT fournit une correspondance plus étroite avec la sémantique spécifiée dans la norme SQL.
- Attention au privilège CREATEROLE. Il n'y a pas de concept d'héritage pour les privilèges d'un rôle CREATEROLE. Cela signifie que même si un rôle n'a pas un certain privilège mais est autorisé à créer d'autres rôles, il peut facilement créer un autre rôle avec des privilèges différents du sien (sauf pour créer des rôles avec des privilèges de superutilisateur). Par exemple, si le rôle «user» a le privilège CREATEROLE mais pas le privilège CREATEDB, il peut néanmoins créer un nouveau rôle avec le privilège CREATEDB. Par conséquent, considérez les rôles ayant le privilège CREATEROLE comme presque des rôles de superutilisateur.
- Le PostgreSQL inclut un programme createuser ayant la même fonctionnalité que CREATE ROLE (en fait, il appelle cette commande) mais peut être exécuté à partir de l'interpréteur de commande.
- L'option CONNECTION LIMIT n'est appliquée qu'approximativement ; si deux nouvelles sessions démarrent à peu près au même moment alors qu'il ne reste qu'un seul «emplacement» de connexion pour le rôle, il est possible que les deux échouent. De plus, la limite n'est jamais appliquée pour les superutilisateurs.
- Des précautions doivent être prises lors de la spécification d'un mot de passe non crypté avec cette commande. Le mot de passe sera transmis au serveur en clair et il peut également être enregistré dans l'historique des commandes du client ou dans le journal du serveur. La commande createuser, cependant, transmet le mot de passe crypté. De plus, psql contient une commande \password pouvant être utilisée pour modifier ultérieurement le mot de passe en toute sécurité.
Dernière mise à jour : Jeudi, le 14 Octobre 2021