Quels sont les privilèges requis pour exécuter une fonction de déclenchement dans PostgreSQL 8.4?


11

Quels sont les privilèges requis pour exécuter une fonction de déclenchement dans PostgreSQL 8.4?

Il semble que les privilèges définis sur un rôle n'ont pas d'importance pour exécuter une fonction de déclenchement. Je pense avoir vu un jour que les privilèges requis pour exécuter une fonction déclencheur sont le privilège EXECUTE mais pour le propriétaire de la table, pas le rôle réel qui exécute l'action qui déclenche le déclencheur qui appelle la fonction déclencheur.

Je ne trouve pas la partie documentation qui explique ce point, une aide?

Réponses:


10

Les fonctions de déclenchement se comportent comme les autres fonctions en ce qui concerne les privilèges. À une exception près:

Pour créer un déclencheur sur une table, l'utilisateur doit avoir le TRIGGER privilège sur la table. L'utilisateur doit également avoir des EXECUTEprivilèges sur la fonction de déclenchement.

MISE À JOUR Après les commentaires dans les commentaires, j'ai fait quelques recherches. Il y a un élément TODO ouvert dans le wiki Postgres:

Resserrer les contrôles des autorisations de déclenchement

Lié à ce fil sur les pirates Postgres . Actuellement, les EXECUTEprivilèges sur une fonction de déclenchement ne sont vérifiés qu'au moment de la création du déclencheur , mais pas au moment de l'exécution. La révocation de EXECUTE sur la fonction de déclenchement n'a donc aucun effet sur un déclencheur une fois créé. Votre observation semble être correcte.

Cela n'accorde aucun privilège supplémentaire pour manipuler des objets. Si le rôle appelant n'a pas les privilèges nécessaires pour exécuter (certaines parties) du corps de la fonction, l'exception habituelle est levée. Pour ouvrir la voie, vous pouvez faire un utilisateur privilégié OWNERde la fonction et utiliser le

SECURITY DEFINER

clause, comme indiqué dans le manuel ici . Il provoque l'exécution de la fonction avec les autorisations du propriétaire au lieu de l' appelant (par défaut).

Si le propriétaire est un superutilisateur, vous devez faire très attention à qui vous accordez le EXECUTEprivilège et ce que la fonction peut faire pour éviter les abus. Vous voudrez peut-être

REVOKE ALL ON FUNCTION foo() FROM public;

pour commencer et utiliser SET search_pathpour la fonction.
Assurez-vous de lire le chapitre sur les fonctions d' écriture en SECURITY DEFINERtoute sécurité .

Trouvez un exemple de code dans cette réponse connexe sur SO.


Non, je ne veux pas de SECURITY DEFINER, je veux de SECURITY INVOKER. Mais il semble (pour la fonction déclencheur, pas pour la fonction régulière) qu'en utilisant l'option par défaut ( SECURITY INVOKER), il n'agit pas ainsi.

1
@EtienneRouxel: les fonctions de déclenchement sont des fonctions comme les autres fonctions en ce qui concerne les privilèges. Qu'est-ce qui vous fait penser le contraire?
Erwin Brandstetter

@EtienneRouxel: J'ai ajouté un devis dans le manuel pour documenter une exception mineure.
Erwin Brandstetter

1
Test: J'ai créé une fonction de déclenchement simple qui déclenche un NOTICE. J'ai supprimé les ALLprivilèges du PUBLICpropriétaire de la fonction. Ensuite, si j'utilise le propriétaire ou tout autre rôle qui n'a aucun privilège sur cette fonction, je dois m'attendre à une erreur en raison d'un manque de privilèges mais tout fonctionne correctement.

2
@EtienneRouxel: Intéressant. J'ai aussi testé. Vous ne pouvez pas créer le déclencheur si vous ne disposez pas du privilège d'exécution pour la fonction de déclencheur. Mais vous pouvez toujours révoquer ce privilège d'exécution après avoir créé le déclencheur et le déclencheur ne cessera pas de fonctionner. J'ai fait des recherches. Ajout de liens à la question ...
Erwin Brandstetter
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.