Généralités sur les droits et les rôles avec PostgreSQL
Les mécanismes d’ASGARD mettent à profit et déclinent les possibilités offertes par PostgreSQL en matière de gestion des droits et, plus largement, d’administration des bases de données. Ils ne remettent pas en cause les règles de gestion des droits sous PostgreSQL. En particulier, si une opération était interdite sans ASGARD pour cause de permissions insuffisantes, elle ne sera pas davantage autorisée avec ASGARD.
Dans cette partie sont rappelées quelques notions de gestion des droits sous PostgreSQL qui s’avèrent particulièrement importantes dans le contexte d’ASGARD.
Complément : ⚓
Pour de plus amples informations, on pourra se reporter :
à la documentation de PostgreSQL, notamment ses parties consacrées aux droits et aux rôles ;
au support pédagogique de la formation à distance PostgreSQL/PostGIS publié sur Géoinformations, notamment son module 2.
Prérogatives du propriétaire⚓
Le rôle désigné comme propriétaire d’un objet (schéma, table…) est seul habilité à supprimer cet objet (DROP) ou modifier sa définition (commande ALTER, ou CREATE OR REPLACE sur un objet pré-existant). Ces droits sont intrinsèques à la propriété – ils ne peuvent ni être conférés à d’autres, ni être révoqués.
PostgreSQL permet cependant au propriétaire d’attribuer d’autres privilèges aux rôles qu’il souhaite sur les objets qui lui appartiennent : droit d’accéder à l’objet (dans le cas d’un schéma, par exemple), de l’utiliser (par exemple pour une fonction), de voir ou de modifier les données qu’il contient (dans le cas d’une table ou assimilé), etc.
Remarque :
À noter que beaucoup d'actions qui ne peuvent être effectuées que par le propriétaire d'un objet requièrent de disposer également d'autres privilèges. Par exemple, supprimer un schéma impose à la fois d'en être le propriétaire et d'être habilité à gérer les schémas de la base (privilège CREATE sur la base).
Rôle de connexion et rôle de groupe⚓
ASGARD adopte l’organisation habituelle suivante :
L’administrateur définit des rôles de connexion (attribut LOGIN), qui permettent aux utilisateurs de se connecter à la base, et des rôles de groupe (attribut NOLOGIN).
Conseil :
Les droits sur les objets sont exclusivement accordés aux rôles de groupe.
Dans cet esprit, un rôle de connexion ne reçoit pas de droit direct, mais il hérite des droits du ou des rôles de groupe auxquels il appartient.
Attributs CREATEROLE et CREATEDB⚓
Comme l’attribut LOGIN mentionné au paragraphe précédent, les attributs CREATEROLE et CREATEDB peuvent être conférés à un rôle au moment de sa création ou, a posteriori, en modifiant sa définition (par une commande ALTER ROLE).
Un rôle disposant de l’attribut CREATEROLE peut gérer les rôles : octroyer ou révoquer l’appartenance d’un rôle à un autre, créer de nouveaux rôles, modifier les attributs des rôles existants et supprimer des rôles (tout ceci hors rôles super-utilisateurs).
Pour sa part, l’attribut CREATEDB est nécessaire pour créer des bases de données, modifier leur nom et leur propriétaire, ou encore les supprimer.
L’administrateur de données localisées (ADL) du service est pleinement légitime à disposer de ces deux attributs, cependant ils ne doivent pas être délégués à la légère à d’autres utilisateurs. En particulier, on retiendra qu’un rôle doté de CREATEROLE peut théoriquement agir sur tous les objets dont le propriétaire n’est pas un super-utilisateur simplement en se rendant membre de leur rôle propriétaire.
Au contraire des droits sur les objets, un rôle n’hérite pas directement des attributs des rôles de groupe dont il est membre.
Exemple :
Si le rôle de connexion C est membre du rôle de groupe G, il doit explicitement endosser le rôle G pour bénéficier des attributs de ce dernier :
SET ROLE role_g ;
Il n’a alors plus accès à ses propres attributs jusqu’à ce qu’il réalise l’opération inverse :
SET ROLE role_c ;
… ou encore
RESET ROLE ;
Ainsi, il est souvent préférable de conférer directement les attributs CREATEDB et CREATEROLE aux rôles de connexion des utilisateurs concernés, d’autant que ceux-ci se doivent de rester très peu nombreux.
Conseil :
Pour autoriser à un utilisateur à créer des rôles ou des bases, on donne à son rôle de connexion l’attribut CREATEROLE ou, respectivement, l’attribut CREATEDB.
Exemple :
Pour habiliter le rôle de connexion jon.snow à gérer les rôles :
ALTER ROLE "jon.snow" WITH CREATEROLE ;