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.
SECURITY DEFINER, je veux deSECURITY 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.