Rôles et autorisations

La section Autorisations est un navigateur de rôles et de privilèges pour PostgreSQL. Elle présente les rôles d’un serveur à la manière du Finder, en colonnes côte à côte : choisissez un rôle à gauche, et les colonnes à sa droite montrent de quels rôles il est membre, quels rôles sont membres de lui, et ce qu’il peut réellement faire sur chaque objet de la base de données — y compris tout ce dont il ne dispose qu’indirectement, par le biais d’appartenances à des rôles héritées ou de PUBLIC. Les rôles, les appartenances, les privilèges, les privilèges par défaut et la propriété peuvent être créés, modifiés et révoqués directement à cet endroit.

Remarque : cette section ne prend actuellement en charge que PostgreSQL. Pour toute autre connexion, elle affiche Les autorisations ne sont pas encore prises en charge pour … / Actuellement, seul PostgreSQL est pris en charge.

Ouvrir la section

Cliquez sur l’icône Autorisations (l’icône représentant des personnes) dans la barre de navigation de gauche. La section fonctionne sur une connexion déjà ouverte dans la section Base de données : la même bande d’onglets de connexion ouverts est affichée en haut, et la section utilise l’onglet de connexion qui y est sélectionné. Si aucune connexion n’est ouverte, elle affiche Aucune connexion ouverte — ouvrez-en d’abord une (voir Gérer les bases de données). Les colonnes sont reconstruites chaque fois que vous entrez dans la section ; toute sélection antérieure est donc réinitialisée.

Tout ce que vous faites ici nécessite les mêmes privilèges que le SQL équivalent (CREATEROLE, superutilisateur ou propriété de l’objet, selon l’action) — OmniDB exécute les instructions avec les identifiants de la connexion que vous utilisez. Les trois colonnes peuvent être redimensionnées en faisant glisser la fine poignée située sur leur bord droit ; un double clic sur une poignée réinitialise cette colonne, et les largeurs sont mémorisées.

Colonne 1 : Rôles

La colonne Rôles liste tous les rôles du serveur, y compris les rôles intégrés pg_*, triés par nom. Les rôles qui peuvent se connecter (utilisateurs) ont une icône à une personne ; ceux qui ne le peuvent pas (groupes) ont une icône à deux personnes ; les superutilisateurs sont signalés par (superutilisateur) et les rôles dont le compte a expiré par (expiré). La première ligne est toujours PUBLIC (icône de globe) — ce n’est pas un vrai rôle, mais le pseudo-rôle auquel chaque rôle appartient implicitement, afin que les privilèges accordés à PUBLIC puissent être consultés et modifiés de la même manière.

La zone de saisie située au-dessus de la liste filtre les rôles par nom, et la liste déroulante à côté par type : Tous les rôles, Utilisateurs (connexion possible), Groupes (sans connexion), Superutilisateurs ou Expirés.

Cliquez sur un rôle pour le rendre actif ; les autres colonnes affichent alors ce rôle. Sous la liste :

• + ouvre la boîte de dialogue Créer un rôle : Nom du rôle, Mot de passe, et les cases d’attributs Peut se connecter (cochée par défaut), Superutilisateur, Peut créer des bases de données, Peut créer des rôles, Hérite des privilèges des rôles dont il est membre (cochée par défaut), Peut lancer une réplication et Contourne la sécurité au niveau des lignes (RLS), ainsi que Limite de connexions (-1 = illimité) et Expiration du compte (laisser vide pour aucune expiration).
• − supprime le rôle sélectionné (désactivé pour PUBLIC).

Un clic droit sur un rôle (autre que PUBLIC) propose :

• Changer le mot de passe — demande deux fois le nouveau mot de passe. Le mot de passe est haché dans le format pour lequel le serveur lui-même est configuré (SCRAM-SHA-256 ou md5) avant d’être envoyé.
• Modifier les attributs — les mêmes champs d’attributs que Créer un rôle, préremplis avec les valeurs actuelles du rôle. Vider Expiration du compte supprime l’expiration.
• Renommer le rôle — ALTER ROLE … RENAME TO. Les privilèges, appartenances et la propriété suivent le rôle ; la boîte de dialogue avertit que PostgreSQL efface un mot de passe stocké en md5 lors du renommage.
• Exporter les permissions / Exporter les permissions de tous les rôles — un script SQL copiable qui recrée les permissions : CREATE ROLE (attributs uniquement), appartenances, privilèges directs sur les objets et privilèges par défaut, les instructions de chaque base de données étant placées sous leur propre en-tête. Chaque partie peut être désactivée et le script se régénère ; Enregistrer dans un fichier… le stocke (une boîte de dialogue d’enregistrement native dans l’application de bureau, un téléchargement dans le navigateur). Les mots de passe, les droits de PUBLIC, la propriété et les réglages des rôles ne sont pas exportés.
• Cloner le rôle — crée un nouveau rôle avec les attributs du rôle source et, en option, ses appartenances directes et ses privilèges directs sur les objets dans toutes les bases de données (repérés via pg_shdepend, si bien que les bases où il ne détient rien ne sont jamais ouvertes). Le mot de passe n’est pas copié ; vous pouvez en définir un dans la boîte de dialogue. Les privilèges par défaut, les objets possédés et les réglages propres au rôle ne sont pas copiés.
• Supprimer le rôle — si le rôle possède encore des objets ou détient des privilèges, la boîte de dialogue liste, par base de données, ce qu’il possède et détient, et demande quel rôle reprend ses objets. OmniDB exécute ensuite REASSIGN OWNED et DROP OWNED dans chaque base concernée (dans cet ordre, afin que rien ne soit supprimé) avant DROP ROLE. Sans aucune dépendance, il demande simplement une confirmation.

Colonne 2 : appartenances

La deuxième colonne est divisée en deux moitiés :

• … — Membres (en haut) : les rôles qui sont membres du rôle actif. Lorsque PUBLIC est actif, elle liste tous les rôles, puisqu’ils reçoivent tous implicitement les privilèges de PUBLIC.
• … — Membre de (en bas) : tous les rôles auxquels appartient le rôle actif, directement ou par l’intermédiaire d’autres rôles, réunis en une seule liste. PUBLIC figure toujours en premier.

Dans les deux moitiés, les appartenances directes sont affichées en texte normal et les appartenances indirectes (héritées) en italique avec une icône estompée. Une appartenance directe accordée WITH ADMIN OPTION est signalée par (admin option) ; à partir de PostgreSQL 16, (sans héritage) et (sans SET) signalent les appartenances qui n’ont pas l’option INHERIT ou SET.

• Le + sous Membre de ouvre Accorder l’appartenance : choisissez un ou plusieurs rôles (cliquez sur les lignes pour les basculer) dont le rôle actif deviendra membre, éventuellement Avec option d’administration (admin option). À partir de PostgreSQL 16, la boîte de dialogue propose aussi des choix INHERIT et SET (Défaut du serveur / Oui / Non).
• Le + sous Membres ouvre Ajouter un membre : la même boîte de dialogue dans l’autre sens — les rôles choisis deviennent membres du rôle actif.
• − (ou clic droit → Retirer l’appartenance) révoque une appartenance après avoir demandé Révoquer l’appartenance au rôle « … » ?. Seules les appartenances directes peuvent être retirées ; une appartenance héritée doit être révoquée là où elle est réellement accordée.
• Clic droit → Modifier les options d’appartenance modifie sur place l’option d’administration d’une appartenance directe et (à partir de PostgreSQL 16) ses options INHERIT/SET.
• Un double clic sur une ligne, ou clic droit → Définir comme rôle actif, fait de ce rôle le rôle actif, exactement comme si vous aviez cliqué dessus dans la colonne Rôles — le moyen le plus rapide de remonter une chaîne d’héritage.

Colonne 3 : objets et privilèges effectifs

La troisième colonne, … — Objets, est une arborescence de tout ce sur quoi le rôle actif possède un privilège quelconque — ses privilèges effectifs : ses propres droits accordés directement, plus tout ce qu’il hérite par ses appartenances et par PUBLIC. Elle commence par deux groupes, Bases de données (toutes les bases de données du serveur) et Tablespaces ; un nœud est affiché normalement si le rôle y possède un privilège, et en grisé sinon. La zone de saisie en haut filtre les bases de données et les tablespaces par nom et conserve son texte lorsque vous changez de rôle.

Le dépliage d’une base de données charge ses objets via une connexion distincte à cette base (la base active de l’onglet de connexion ne change pas) : les Schémas et, dans chaque schéma, des dossiers pour les Tables, Vues, Séquences, Fonctions, Procédures, Vues matérialisées, Types et Domaines ; les wrappers de données distantes (foreign data wrappers) et les serveurs distants se trouvent directement sous la base de données. Seuls les objets sur lesquels le rôle possède réellement un privilège sont listés (les schémas système sont exclus) ; un schéma affiché en grisé n’est présent que parce qu’un élément qu’il contient l’est. Chaque base de données possède aussi deux dossiers supplémentaires : Objets possédés (n), qui liste ce que le rôle y possède (jusqu’à 1000 entrées), et Privilèges par défaut, décrit plus bas. S’il n’y a rien du tout, la base de données affiche Aucun privilège sur les objets de cette base de données.

Modifier les privilèges

Faites un clic droit sur une base de données, un tablespace, un schéma ou un objet et choisissez Modifier les privilèges. La boîte de dialogue liste sous forme de cases à cocher chaque privilège valide pour ce type d’objet :

• base de données : CREATE, CONNECT, TEMPORARY ;
• tablespace : CREATE ; schéma : CREATE, USAGE ;
• table, vue et vue matérialisée : SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER ;
• séquence : USAGE, SELECT, UPDATE ;
• fonction et procédure : EXECUTE ;
• type, domaine, wrapper de données distantes et serveur distant : USAGE.

Les cases indiquent ce que le rôle détient directement :

• cochée — accordé directement au rôle ; décochez-la pour le révoquer (REVOKE) ;
• non cochée — non accordé directement ; cochez-la pour l’accorder (GRANT). Si le rôle possède déjà le privilège par un autre rôle ou par PUBLIC, la case reste non cochée et est étiquetée Hérité de : … — vous pouvez quand même la cocher pour l’accorder directement, afin qu’il survive à la suppression de l’appartenance dont il provient. Pour retirer un privilège hérité, révoquez-le à sa source (rendez le rôle source actif avec Définir comme rôle actif).

Avec option de transmission (grant option) s’applique aux privilèges que vous accordez nouvellement dans cette boîte de dialogue. Validez avec Enregistrer.

Pour accorder un privilège sur un objet qui ne figure pas encore dans l’arborescence, utilisez le + (Ajouter un privilège sur un objet) sous la colonne : choisissez le Type d’objet, puis la Base de données (pour tout sauf les bases de données et les tablespaces ; par défaut, la base de données actuelle de la connexion), le Schéma pour les objets de niveau schéma, l’Objet lui-même (les fonctions sont affichées avec la signature de leurs arguments), cochez les Privilèges et, éventuellement, Avec option de transmission (grant option). Pour les tables, séquences, fonctions et procédures, le choix Portée peut passer de Objet sélectionné à Toutes les … du schéma, avec Accorder ou Révoquer : OmniDB exécute alors GRANT/REVOKE … ON ALL … IN SCHEMA, ce qui concerne les objets existant actuellement, et non ceux créés plus tard.

Sélectionner PUBLIC dans la première colonne vous permet de modifier ce qui est accordé à PUBLIC lui-même (GRANT … TO PUBLIC / REVOKE … FROM PUBLIC).

Privilèges par défaut

Le dossier Privilèges par défaut d’une base de données liste les entrées ALTER DEFAULT PRIVILEGES qui impliquent le rôle actif, soit comme bénéficiaire, soit comme rôle créateur. Ils permettent de couvrir les objets créés à l’avenir. Faites un clic droit sur le dossier pour Ajouter des privilèges par défaut : choisissez le rôle créateur (Pour les objets créés par), le schéma (ou tous les schémas), le type d’objet (tables, séquences, fonctions, types, schémas) et les privilèges. Faites un clic droit sur une entrée existante pour Modifier les privilèges (seules les cases que vous changez sont accordées ou révoquées) ou Supprimer les privilèges par défaut.

Propriété et qui a accès

• Changer le propriétaire (menu contextuel de n’importe quel objet de la colonne Objets) exécute ALTER … OWNER TO sur l’objet.
• Qui a accès est la vue inverse : elle liste chaque rôle qui peut faire quelque chose avec l’objet et pourquoi — propriétaire, droit direct, hérité par une appartenance ou superutilisateur — ainsi que PUBLIC, avec des marques pour l’option de transmission. Les réponses proviennent des fonctions has_*_privilege de PostgreSQL lui-même, elles correspondent donc à ce que le serveur autorise réellement. Les rôles qui n’ont que ce que PUBLIC donne à tout le monde sont omis et les superutilisateurs sont regroupés dans un groupe replié ; un clic sur un rôle en fait le rôle actif.

Aperçu du SQL

Les boîtes de dialogue de création, de modification, de renommage et de clonage de rôles, d’ajout d’appartenances, d’octroi ou de modification de privilèges, de privilèges par défaut et de changement de propriétaire disposent d’une zone repliable Afficher le SQL. Elle montre les instructions exactes que les valeurs actuelles du formulaire exécuteraient — construites par le même code serveur que l’appel réel, rien n’est exécuté, les mots de passe sont masqués — et les tient à jour au fur et à mesure que le formulaire change. Copier le SQL les copie.

Important : valider une boîte de dialogue exécute les instructions sur le serveur immédiatement — il n’y a pas d’annulation. Relisez-les d’abord avec Afficher le SQL. Supprimer le rôle, Retirer l’appartenance et Supprimer les privilèges par défaut demandent aussi une confirmation. Si le serveur rejette une instruction, son message d’erreur est affiché.