g_admin

Rôle de groupe pour les administrateurs du serveur PostgreSQL, qui permet de gérer les rôles, les schémas et les droits des rôles sur les schémas et leur contenu. Il est créé par l'extension ASGARD lors de sa première activation sur une base du serveur. De nombreuses fonctionnalités d'ASGARD ne sont accessibles qu'aux utilisateurs membres de g_admin.

Attention

Le rôle g_admin est requis par ASGARD, il ne doit surtout pas être supprimé.

g_admin est le groupe[1] des administrateurs.

Ce n’est pas un rôle de connexion[2] (attribut NOLOGIN) et ce n’est pas un super-utilisateur[3] (NOSUPERUSER), mais il peut créer, modifier et supprimer des bases (CREATEDB), créer, gérer et supprimer des rôles (CREATEROLE) et passer outre les politiques de sécurité définies sur les tables (BYPASSRLS). Il a de plus le privilège CREATE sur la base avec « GRANT OPTION », ce qui lui permet de créer de nouveaux schémas et de conférer ce droit à d’autres rôles.

Ce rôle est essentiel pour le système de gestion des droits, qui prévoit que lui seul soit habilité à réaliser les actions les plus sensibles et veille à ce qu’il puisse intervenir sur tous les objets de la base, notamment en le rendant automatiquement membre de tous les rôles désignés comme producteurs[4] (hors super-utilisateurs).

Remarque

Aucun contrôle n’est réalisé a posteriori : g_admin reste membre du rôle même s’il n’est plus producteur d’aucun schéma et ASGARD n’empêche pas de retirer à g_admin des permissions sur certains rôles producteurs. C’est toutefois déconseillé (il est souhaitable que l’administrateur puisse agir sur l’ensemble du patrimoine en cas de problème) et foncièrement inutile, l’attribut CREATEROLE autorisant g_admin à s’auto-octroyer l’appartenance à tous les rôles hors super-utilisateurs.

g_admin est également le producteur par défaut des schémas de la nomenclature nationale[5] – ce qui peut bien entendu être modifié a posteriori.

Compte-tenu de l’étendue de ses prérogatives, à peine inférieures à celles d’un super-utilisateur, le rôle g_admin devrait être strictement réservé aux administrateurs du serveur PostgreSQL.

Conseil

Seuls le ou les administrateurs du serveur sont membres de g_admin.

Pour le bon fonctionnement d’ASGARD, il est essentiel que le rôle g_admin ne soit pas renommé après l’installation et reste quoi qu’il arrive propriétaire du schéma z_asgard_admin et de la table gestion_schema.

Ne pas modifier les permissions de g_admin sur les objets d’ASGARD.

Que g_admin dispose des attributs CREATEROLE et CREATEDB n’interdit pas de doter directement les rôles de connexion des administrateurs de ces attributs. Cette pratique simplifie considérablement les manipulations courantes sur les rôles (cf. Attributs CREATEROLE et CREATEDB), notamment celles qui ne sont pas réalisées via la table de gestion[6] d’ASGARD.

Complément⚓

Pour les opérations effectuées par l'intermédiaire de la table de gestion, ASGARD saura identifier qu’un rôle de connexion est membre d’un rôle de groupe disposant de CREATEROLE et lui faire endosser temporairement ce rôle lorsque la situation l'exige - s'il lui faut par exemple créer de nouveaux rôles. Ce n’est pas le cas avec des commandes SQL ordinaires, comme CREATE ROLE ou ALTER ROLE, qui échoueront avec un message d’erreur tel que « ERREUR: droit refusé pour créer un rôle ».

Comme mentionné précédemment, ASGARD rend systématiquement g_admin membre des rôles désignés comme producteurs d’un schéma (lorsqu’il ne l’est pas déjà).

Automatique, cette opération ne nécessite aucune intervention de l’utilisateur. Elle ne requiert pas non plus de l'utilisateur qu'il soit habilité à rendre un autre rôle membre du rôle producteur, ce qui supposerait ordinairement qu'il dispose de l’attribut CREATEROLE ou soit membre dudit rôle producteur avec ADMIN OPTION. Ce sont en fait les prérogatives de g_admin qui sont utilisées par la fonction z_asgard_admin.asgard_visibilite_admin_after().

Elle a par contre une conséquence immédiate, PostgreSQL n'autorisant pas les permissions circulaires sur les rôles :

Un rôle producteur de schéma ne doit jamais être membre de g_admin, y compris par héritage.