Quels sont les droits utilisateur nécessaire pour pouvoir exécuter ALTER TABLE "..." DISABLE TRIGGER ALL ?

Bonjour,

quand j'exécute la requête

ALTER TABLE "Laboratory" DISABLE TRIGGER ALL;

avec un utilisateur non admin "foobar" j'ai l'erreur suivante :

ERREUR: droit refusé : « RI_ConstraintTrigger_21913 » est un trigger
système

Cet utilisateur "foobar" a les droits suivant :

rolsuper : f
rolinherit : t
rolcreaterole : f
rolcreatedb : t
rolcatupdate : f
rolcanlogin : t

J'aimerai savoir qu'est ce que je dois modifier au niveau de mon
utilisateur "foobar" pour qu'il puisse créer et détruire des triggers ?

Quand je réalise ALTER TABLE "Laboratory" DISABLE TRIGGER ALL; avec les
droits administrateur (utilisateur postgres), ça fonctionne correctement.

Merci d'avance pour votre aide.

Cordialement,
Stéphane

--
Stéphane Klein <stephane(at)harobed(dot)org> - French
blog: http://stephane-klein.info
twitter: http://twitter.com/klein_stephane
pro: http://www.is-webdesign.com

The Tuesday 19 October 2010 16:58:00, Stéphane Klein wrote :
> Bonjour,
>
> quand j'exécute la requête
>
> ALTER TABLE "Laboratory" DISABLE TRIGGER ALL;
>
> avec un utilisateur non admin "foobar" j'ai l'erreur suivante :
>
> ERREUR: droit refusé : « RI_ConstraintTrigger_21913 » est un trigger
> système
>
>
> Cet utilisateur "foobar" a les droits suivant :
>
> rolsuper : f
> rolinherit : t
> rolcreaterole : f
> rolcreatedb : t
> rolcatupdate : f
> rolcanlogin : t
>
> J'aimerai savoir qu'est ce que je dois modifier au niveau de mon
> utilisateur "foobar" pour qu'il puisse créer et détruire des triggers ?
>
> Quand je réalise ALTER TABLE "Laboratory" DISABLE TRIGGER ALL; avec les
> droits administrateur (utilisateur postgres), ça fonctionne correctement.
>
> Merci d'avance pour votre aide.
>
> Cordialement,
> Stéphane

Désolé pour le temps de réponse (le temps de monter un test :) )

À priori, c'est sans solution propre:

le trigger RI_ConstraintTrigger_21913 implémente une foreign key. C'est un
trigger système, puisque vous ne l'avez pas créé (vous avez fait un alter
table Laboratory add foreign key…).

Si vous voulez ne pas avoir l'erreur, vous devrez désactiver (probablement
même supprimer) la contrainte d'intégrité.

Ou bien mettre votre utilisateur superuser (ce qui est assez limite niveau
sécurité, si c'est un utilisateur applicatif).

Malgré tout, c'est dans la doc:
http://docs.postgresql.fr/8.4/sql-altertable.html

«ALL
Désactiver ou activer tous les déclencheurs appartenant à la table. (Les
droits de superutilisateur sont nécessaires si l'un des déclencheurs concerne
une contrainte de clé étrangère.)»

Même si je trouve que c'est un peu un gotcha à la MySQL…

==== Digression ====

Je ne suis pas sûr que quelqu'un qui demande la désactivation de tous les
triggers d'une table veuille vraiment qu'on lui désactive aussi ses
contraintes d'intégrité. Et je suis encore moins sûr qu'il veuille qu'on lui
réactive ses contraintes d'intégrité sans recontrôler la cohérence… (je
n'étais pas conscient qu'on pouvait faire ça :( )

Par exemple:

CREATE TABLE test (a int);
CREATE TABLE test2 (a int primary key);
ALTER TABLE test add foreign key (a) references test2(a);

INSERT INTO test values(1);
ERROR: insert or update on table "test" violates foreign key constraint
"test_a_fkey"
DETAIL: Key (a)=(1) is not present in table "test2".

=> Normal

ALTER TABLE test DISABLE TRIGGER all;
INSERT INTO test values(1);

=> Pas vraiment normal

ALTER TABLE test ENABLE TRIGGER all;

=> Pas de revalidation. Ouch. On a une base avec une contrainte d'intégrité en
place, mais l'intégrité qui est fausse.

Des avis là-dessus ?

Marc Cousin <cousinmarc(at)gmail(dot)com> writes:
> => Pas de revalidation. Ouch. On a une base avec une contrainte d'intégrité en
> place, mais l'intégrité qui est fausse.
>
> Des avis là-dessus ?

C'est un piège qu'on rencontre en général avec backup impossible à
restorer complètement, et ce n'est jamais une bonne surprise. De mémoire
il me semble qu'il faut particulièrement être prudent avec les bases qui
ont été mises à jour successivement depuis une 7.3, mais pas toujours en
ayant appliqué le script adddepend…

Bref, c'est pour cela que l'option est superuser only : elle peut être
bien pratique dans certains cas, mais il faut vraiment savoir ce que
l'on fait.

Étant la restriction superuser, je ne pense pas que l'on puisse appeler
cela un Gotcha au sens de ta référence, mais c'est un joli piège oui :)

(ça serait un Gotcha si ça ne faisait pas ce que tu demandes)

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

The Wednesday 20 October 2010 13:59:10, Dimitri Fontaine wrote :
> Marc Cousin <cousinmarc(at)gmail(dot)com> writes:
> > => Pas de revalidation. Ouch. On a une base avec une contrainte
> > d'intégrité en place, mais l'intégrité qui est fausse.
> >
> > Des avis là-dessus ?
>
> C'est un piège qu'on rencontre en général avec backup impossible à
> restorer complètement, et ce n'est jamais une bonne surprise. De mémoire
> il me semble qu'il faut particulièrement être prudent avec les bases qui
> ont été mises à jour successivement depuis une 7.3, mais pas toujours en
> ayant appliqué le script adddepend…
>
> Bref, c'est pour cela que l'option est superuser only : elle peut être
> bien pratique dans certains cas, mais il faut vraiment savoir ce que
> l'on fait.
>
> Étant la restriction superuser, je ne pense pas que l'on puisse appeler
> cela un Gotcha au sens de ta référence, mais c'est un joli piège oui :)
>
> (ça serait un Gotcha si ça ne faisait pas ce que tu demandes)

Je faisais évidemment référence à ça:
http://sql-info.de/mysql/gotchas.html

«It's not a bug - it's a gotcha. A "gotcha" is a feature or function which
works as advertised - but not as expected.»

(bonne lecture, au passage, pour ceux qui veulent d'encore meilleures raisons
de ne pas aimer mysql…)

C'est justement ce sur quoi je suis un peu mal à l'aise sur cette
fonctionnalité: pour moi, désactiver les triggers sur une table, ça veut dire
désactiver ce qui a été déclaré explicitement comme trigger. D'où le gotcha,
il ne fait pas du tout ce à quoi je m'attendais: c'est pas mon problème qu'il
implémente ses contraintes avec des triggers. Il le ferait avec un bout de
Cobol 95, je m'en foutrais tout autant (quoique :) )

Bon, d'un autre côté, je ne l'utilise jamais, je ne désactive que des triggers
dont j'ai vérifié l'existence et le sens avant, alors je me demande pourquoi
je râle :)

Le 20 octobre 2010 13:38, Marc Cousin <cousinmarc(at)gmail(dot)com> a écrit :
> The Tuesday 19 October 2010 16:58:00, Stéphane Klein wrote :
>> Bonjour,
>>
>> quand j'exécute la requête
>>
>> ALTER TABLE "Laboratory" DISABLE TRIGGER ALL;
>>
>> avec un utilisateur non admin "foobar" j'ai l'erreur suivante :
>>
>> ERREUR:  droit refusé : « RI_ConstraintTrigger_21913 » est un trigger
>> système
>>
>>
>> Cet utilisateur "foobar" a les droits suivant :
>>
>> rolsuper : f
>> rolinherit : t
>> rolcreaterole : f
>> rolcreatedb : t
>> rolcatupdate : f
>> rolcanlogin : t
>>
>> J'aimerai savoir qu'est ce que je dois modifier au niveau de mon
>> utilisateur "foobar" pour qu'il puisse créer et détruire des triggers ?
>>
>> Quand je réalise ALTER TABLE "Laboratory" DISABLE TRIGGER ALL; avec les
>> droits administrateur (utilisateur postgres), ça fonctionne correctement.
>>
>> Merci d'avance pour votre aide.
>>
>> Cordialement,
>> Stéphane
>
> Désolé pour le temps de réponse (le temps de monter un test :) )
>
> À priori, c'est sans solution propre:
>
> le trigger RI_ConstraintTrigger_21913 implémente une foreign key. C'est un
> trigger système, puisque vous ne l'avez pas créé (vous avez fait un alter
> table Laboratory add foreign key…).
>
> Si vous voulez ne pas avoir l'erreur, vous devrez désactiver (probablement
> même supprimer) la contrainte d'intégrité.
>
> Ou bien mettre votre utilisateur superuser (ce qui est assez limite niveau
> sécurité, si c'est un utilisateur applicatif).
>
> Malgré tout, c'est dans la doc:
> http://docs.postgresql.fr/8.4/sql-altertable.html
>
> «ALL
> Désactiver ou activer tous les déclencheurs appartenant à la table. (Les
> droits de superutilisateur sont nécessaires si l'un des déclencheurs concerne
> une contrainte de clé étrangère.)»
>
> Même si je trouve que c'est un peu un gotcha à la MySQL…
>
> ==== Digression ====
>
> Je ne suis pas sûr que quelqu'un qui demande la désactivation de tous les
> triggers d'une table veuille vraiment qu'on lui désactive aussi ses
> contraintes d'intégrité. Et je suis encore moins sûr qu'il veuille qu'on lui
> réactive ses contraintes d'intégrité sans recontrôler la cohérence… (je
> n'étais pas conscient qu'on pouvait faire ça :( )
>
>
> Par exemple:
>
> CREATE TABLE test (a int);
> CREATE TABLE test2 (a int primary key);
> ALTER TABLE test add foreign key (a) references test2(a);
>
> INSERT INTO test values(1);
> ERROR:  insert or update on table "test" violates foreign key constraint
> "test_a_fkey"
> DETAIL:  Key (a)=(1) is not present in table "test2".
>
> => Normal
>
> ALTER TABLE test DISABLE TRIGGER all;
> INSERT INTO test values(1);
>
> => Pas vraiment normal
>
> ALTER TABLE test ENABLE TRIGGER all;
>
> => Pas de revalidation. Ouch. On a une base avec une contrainte d'intégrité en
> place, mais l'intégrité qui est fausse.
>
>
> Des avis là-dessus ?

le mot clef ALL est un mauvais choix pour un utilsateur normal. Cela
signifie qu'en cas d'évolution du schéma l'appli pourrait continuer
une action qui ne serait pas 'propre' (par exemple si un nouveau
trigger est ajouté et qu'il ne faut pas le désactiver)

Si les triggers ont bien été désactivés nommément on réduit les risques.

>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support