Функции триггера ведут себя так же, как и другие функции, что касается привилегий. За небольшим исключением:
Чтобы создать триггер для таблицы, пользователь должен иметь TRIGGER
привилегию для таблицы. Пользователь также должен иметь EXECUTEпривилегию на функцию триггера.
ОБНОВЛЕНИЕ
После обратной связи в комментариях я провел небольшое исследование. В Вики Postgres есть открытый пункт TODO:
Затянуть проверки разрешений триггеров
Связанный с этой темой на хакерах Postgres . В настоящее время EXECUTEпривилегии для функции триггера проверяются только во время создания триггера , но не во время выполнения. Таким образом, отмена EXECUTE для функции триггера не влияет на триггер после его создания. Ваше наблюдение кажется правильным.
Это не дает никаких дополнительных привилегий для манипулирования объектами. Если вызывающая роль не имеет привилегий, необходимых для выполнения (части) тела функции, возникает обычное исключение. Чтобы проложить путь, вы можете сделать привилегированного пользователя OWNERфункции и использовать
SECURITY DEFINER
пункт, как указано в руководстве здесь . Это вызывает запуск функции с разрешениями владельца вместо invoker (по умолчанию).
Если владелец является суперпользователем, вам нужно быть очень осторожным с тем, кому вы предоставляете EXECUTEпривилегию, и что может сделать функция, чтобы избежать злоупотреблений. Вы можете захотеть
REVOKE ALL ON FUNCTION foo() FROM public;
для начала и использовать SET search_pathдля функции.
Обязательно прочитайте главу о безопасном написании SECURITY DEFINERфункций .
Найдите пример кода в этом связанном ответе на SO.
SECURITY DEFINER, я хочуSECURITY INVOKER. Но кажется (для функции триггера, а не для обычной функции), что при использовании опции по умолчанию (SECURITY INVOKER), это не действует так.