Las funciones de activación se comportan igual que otras funciones en lo que respecta a los privilegios. Con una pequeña excepción:
Para crear un activador en una tabla, el usuario debe tener el TRIGGER
privilegio en la tabla. El usuario también debe tener EXECUTE
privilegios en la función de activación.
ACTUALIZACIÓN
Después de los comentarios en los comentarios, investigué un poco. Hay un elemento TODO abierto en el Wiki de Postgres:
Apriete las comprobaciones de permisos de activación
Vinculado a este hilo en los hackers de Postgres . Actualmente, los EXECUTE
privilegios en una función de activación solo se verifican en el momento de creación del activador , pero no en tiempo de ejecución. Por lo tanto, revocar EXECUTE en la función de disparo no tiene efecto en un disparador una vez creado. Tu observación parece ser correcta.
Esto no otorga ningún privilegio adicional para manipular objetos. Si el rol de llamada carece de los privilegios necesarios para ejecutar (partes de) el cuerpo de la función, se genera la excepción habitual. Para allanar el camino, puede hacer un usuario privilegiado OWNER
de la función y usar el
SECURITY DEFINER
cláusula, como se documenta en el manual aquí . Hace que la función se ejecute con los permisos del propietario en lugar del invocador (predeterminado).
Si el propietario es un superusuario, debe tener mucho cuidado a quién le otorga el EXECUTE
privilegio y qué puede hacer la función para evitar abusos. Es posible que desee
REVOKE ALL ON FUNCTION foo() FROM public;
para comenzar y usar SET search_path
para la función.
Asegúrese de leer el capítulo sobre Funciones de escritura de forma SECURITY DEFINER
segura .
Encuentre un ejemplo de código en esta respuesta relacionada en SO.
SECURITY DEFINER
, quiero unSECURITY INVOKER
. Pero parece (para la función de activación, no para la función regular) que al usar la opción predeterminada (SECURITY INVOKER
), no actúa así.