Modification des rôles

Au contraire des noms des schémas, les noms des rôles désignés comme producteur[1], éditeur[2] ou lecteur[3] ne sont pas mis à jour automatiquement dans la table de gestion[4] lorsque ces rôles sont renommés (ALTER ROLE ... RENAME) ou supprimés. La suppression ne concerne bien entendu que les éditeurs et lecteur (après révocation de tous leurs privilèges), PostgreSQL ne permettant pas de supprimer un rôle qui serait propriétaire d’un schéma.

Cependant, lorsqu’un utilisateur intervient sur une ligne de la table de gestion se rapportant à un schéma créé et comportant un nom de rôle obsolète ou inexistant, le champ est actualisé. Lorsqu’un rôle lecteur ou éditeur n’existe plus, le champ est vidé.

Exemple

Le producteur du schéma w_snow est renommé :

1
2
ALTER ROLE g_snum RENAME TO g_mte_snum ;
Sur le moment, rien ne se passe dans la table de gestion. L'ancien nom reste visible.
Toutefois, lorsqu’un utilisateur modifie – par exemple – le rôle désigné comme lecteur pour le schéma, il est informé de la mise à jour du nom du producteur (deux premières lignes des messages).
1
2
UPDATE z_asgard.gestion_schema_usr
3
    SET lecteur = 'g_consult'
4
    WHERE nom_schema = 'w_snow' ;
1
2
NOTICE:  [table de gestion] Schéma w_snow. Mise à jour du libellé du rôle producteur, renommé entre temps.
3
DETAIL:  Ancien nom "g_snum", nouveau nom "g_mte_snum".
4
NOTICE:  suppression et transfert vers le nouveau lecteur des privilèges de l'ancien lecteur du schéma w_snow :
5
NOTICE:  > GRANT USAGE ON SCHEMA w_snow TO g_consult
6
NOTICE:  > REVOKE USAGE ON SCHEMA w_snow FROM public
7
NOTICE:  > GRANT SELECT ON TABLE w_snow.journal_du_mur TO g_consult
8
NOTICE:  > REVOKE SELECT ON TABLE w_snow.journal_du_mur FROM public
9
NOTICE:  > GRANT SELECT ON SEQUENCE w_snow.journal_du_mur_id_seq TO g_consult
10
NOTICE:  > REVOKE SELECT ON SEQUENCE w_snow.journal_du_mur_id_seq FROM public
11
UPDATE 1
Pour mettre à jour en une seule fois toute la table de gestion après la modification d’un rôle, l’administrateur pourra exécuter la fonction asgard_nettoyage_roles.
Lorsque le but poursuivi est la suppression du rôle, il est conseillé d’utiliser la fonction asgard_reaffecte_role, qui propose une méthode rapide et compatible avec ASGARD pour supprimer l’ensemble des droits d’un rôle sur les objets de la base – ou les réaffecter à un autre rôle. Dans ce cas, aucune intervention a posteriori sur la table de gestion n’est nécessaire.
Tout ceci ne concerne cependant que les schémas créés, pour lesquels ASGARD identifie le rôle non par son nom mais par l’identifiant système (OID) invariant que lui attribue PostgreSQL.
Pour les schémas inactifs[5], dont les rôles peuvent ne pas encore exister, ASGARD n’a aucun moyen de distinguer un renommage d’un changement de rôle et ne procédera donc, quoi qu’il arrive (y compris avec les deux fonctions susmentionnées), à aucune modification. Il est du ressort de l’administrateur de s’assurer que les noms pré-renseignés restent conformes à ses attentes et de réaliser les corrections nécessaires par de simples UPDATE sur la vue utilisateur[6].