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 EXECUTE
privilè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 EXECUTE
privilè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é OWNER
de 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 EXECUTE
privilè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_path
pour la fonction.
Assurez-vous de lire le chapitre sur les fonctions d' écriture en SECURITY DEFINER
toute 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.