Suivi de la création/modification des tables appartenant à des super-utilisateurs

[thiegaillard]

Bonjour,

j'ai créé une nouvelle base dans lequel j'ai mis Asgard, Plume et d'autres extensions

• plpgsql (version 1.0)
• postgis (version 3.0.0)
• asgard (version 1.4.0)
• pgcrypto (version 1.3)
• plume_pg (version 0.1.1)
• postgres_fdw (version 1.0)

J'ai ensuite lancé le sql suivant pour initialiser les 3 triggers sur les dates

ALTER EVENT TRIGGER plume_stamp_table_creation ENABLE ; ALTER EVENT TRIGGER plume_stamp_table_modification ENABLE ; ALTER EVENT TRIGGER plume_stamp_table_drop ENABLE ;

Et cela ne fonctionne pas : aucun trigger sur les tables que j'ai rajouté par la suite.

Par contre je peux ajouter ces triggers table par table avec

SELECT z_plume.stamp_create_trigger('schema_name.table_name'::regclass) ;

Je me demande si j'ai oublié quelques choses... Je suis disponible pour vous donner plus de détails s'il le faut.

Merci d'avance pour votre aide.

[alhyss]

Bonjour @thiegaillard,

A priori tu n'oublies rien, les déclencheurs d'enregistrement des dates de modification devraient être automatiquement créés sur toutes tes nouvelles tables.

Néanmoins la fonction appelée par plume_stamp_table_creation a été écrite pour ne pas bloquer la création de la table si elle-même échoue à mettre en place le déclencheur. Je suppose que dans ton cas il a dû se produire une erreur.

Est-ce que tu peux lancer une commande de création de table dans pgAdmin (avec les trois déclencheurs sur évènements actifs) et me dire :

• Si tu vois dans la console un autre message que CREATE TABLE ? En principe tu devrais avoir le descriptif de l'erreur s'il y en a eu une.
• Si la requête suivante te renvoie quelque chose et quoi (en remplaçant bien sûr mon_schema.ma_table par le nom de ta table et son schéma) ?

  SELECT * FROM z_plume.stamp_timestamp WHERE relid = 'mon_schema.ma_table'::regclass ;

[thiegaillard]

J'ai bien une erreur. Quand je lance la création d'une table

CREATE TABLE IF NOT EXISTS w_test.test_declencheur ( test2 text COLLATE pg_catalog."default", bbb integer )

j'ai cette erreur mais la table est bien créée

NOTICE: permission denied for schema w_test DETAIL:
HINT:
CREATE TABLE Requête exécutée avec succès en 228 msec.

Le Permisson denied doit être les triggers (?) pas de trigger plume Le problème est sans-doute un problème de droit.

Pour l'instant, je ne donne aucun droit sur cette base. J'ai même très peu de rôles :

• adl (superuser)
• g_admin, g_admin_ext, g_consult
• les pg_.....
• postgresql
• postgis

Tous les schémas et tables sont créés par adl exemple :

CREATE SCHEMA IF NOT EXISTS w_test AUTHORIZATION adl;

Je ne suis pas un "cador" comme toi des droits, tu as une solution ?

Par contre si je lance à la main

SELECT z_plume.stamp_create_trigger('w_test.test_declencheur'::regclass) ;

pas de problème, j'ai bien pour cette table le trigger

CREATE TRIGGER plume_stamp_data_edit AFTER INSERT OR DELETE OR TRUNCATE OR UPDATE ON w_test.test_declencheur FOR EACH STATEMENT EXECUTE FUNCTION z_plume.stamp_data_edit();

[alhyss]

Tu confirmes que g_admin est le propriétaire/producteur du schéma z_plume ? Normalement c'est ce qui est fait par défaut quand Asgard est présent sur la base, même s'il est tout à fait possible de le changer ensuite.

Si c'est ça, alors ce serait normal. adl étant un super-utilisateur, Asgard n'est pas en mesure de rendre g_admin membre de ce rôle lors de la création du schéma w_test, comme il l'aurait fait avec un autre rôle producteur. Il en découle que g_admin n'a pas accès au schéma w_test et son contenu, alors qu'il aurait eu besoin des privilèges USAGE sur le schéma et TRIGGER sur la table pour créer le déclencheur.

Or PlumePg combine des fonctions SECURITY INVOKER (qui utilisent les privilèges du rôle qui les appelle, ici adl) et des fonctions SECURITY DEFINER (qui utilisent les privilèges du propriétaire de la fonction, ici g_admin, puisqu'il est producteur de z_plume). En temps normal, se baser sur les privilèges de g_admin permet l'exécution d'actions qu'un utilisateur lambda n'aurait pas été capable de réaliser directement. Tu es dans le seul cas où c'est défavorable, car g_admin a moins de droits qu'un super-utilisateur.

D'une manière générale, il faut partir du principe qu'à partir du moment où tu crées des schémas avec un super-utilisateur, Asgard ne sera plus capable de générer automatiquement tous les droits dont tu pourrais avoir besoin. Dans la documentation d'Asgard je conseillais de définir g_admin comme producteur à la place des super-utilisateurs chaque fois que c'est possible.

Une autre solution serait de faire de ton rôle adl le producteur du schéma z_plume. Tes déclencheurs seront alors bien créés automatiquement. Par contre ça te fait un schéma de plus sur lequel g_admin n'a pas la main.

Je vais tout de même regarder si je peux faire en sorte que PlumePg lance la commande de création du déclencheur avec les droits du rôle courant et pas de g_admin sans créer d'effet de bord. Par contre, je pense que l'intégration directe dans les métadonnées ne fonctionnera jamais dans cette configuration, car la fonction qui gère ça doit rester en SECURITY DEFINER pour prendre en compte les modifications réalisées par tous les rôles. Il faudrait que g_admin soit membre du propriétaire de la table pour qu'il puisse modifier son descriptif, et ce n'est donc pas le cas pour les tables d'adl.

[alhyss]

• [ ] Voir s'il est possible de faire de stamp_table_creation() une fonction SECURITY INVOKER, quitte à appeler une fonction SECURITY DEFINER pour la commande UPDATE (mais ne devrait pas être nécessaire puisque stamp_timestamp_access_control() autorise le propriétaire d'une table à modifier son enregistrement dans stamp_timestamp ?).

[thiegaillard]

oui g_admin est propriétaire/producteur du schéma z_plume j'ai mis adl producteur du schéma plume et le déclenchement des triggers se fait

[alhyss]

@thiegaillard Merci de ton retour !