Open thiegaillard opened 1 year ago
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 :
CREATE TABLE
? En principe tu devrais avoir le descriptif de l'erreur s'il y en a eu une.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 ;
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 :
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();
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
.
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
?).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
@thiegaillard Merci de ton retour !
Bonjour,
j'ai créé une nouvelle base dans lequel j'ai mis Asgard, Plume et d'autres extensions
J'ai ensuite lancé le sql suivant pour initialiser les 3 triggers sur les dates
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
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.