¿Cuáles son los privilegios necesarios para ejecutar una función de activación en PostgreSQL 8.4?

11

¿Cuáles son los privilegios necesarios para ejecutar una función de activación en PostgreSQL 8.4?

Parece que los privilegios establecidos para un rol no importan para ejecutar una función de activación. Creo que algún día he visto que los privilegios necesarios para ejecutar una función desencadenante es el privilegio EJECUTAR, pero para el propietario de la tabla, no el rol real que realiza la acción que activa el desencadenante que llama a la función desencadenante.

No puedo encontrar la parte de documentación que explica ese punto, ¿alguna ayuda?

postgresql stored-procedures trigger permissions postgresql-8.4 Erwin Brandstetter
fuente

Respuestas:

10

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 EXECUTEprivilegios 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 EXECUTEprivilegios 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 OWNERde 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 EXECUTEprivilegio 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_pathpara la función.
Asegúrese de leer el capítulo sobre Funciones de escritura de forma SECURITY DEFINERsegura .

Encuentre un ejemplo de código en esta respuesta relacionada en SO.

Erwin Brandstetter
fuente
No, no quiero un SECURITY DEFINER, quiero un SECURITY 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í.
1
@ EtienneRouxel: las funciones de activación son funciones como otras funciones en lo que respecta a los privilegios. ¿Qué te hace pensar lo contrario?
Erwin Brandstetter
@ EtienneRouxel: agregué una cita del manual para documentar una excepción menor.
Erwin Brandstetter
1
Prueba: creé una función de disparo simple que eleva a NOTICE. Eliminé los ALLprivilegios del PUBLICpropietario de la función. Luego, si uso el propietario o cualquier otra función que no tenga ningún privilegio en esa función, debería esperar un error debido a la falta de privilegios, pero todo se ejecuta con éxito.
2
@ EtienneRouxel: Interesante. También lo probé. No puede crear el activador si no tiene el privilegio de ejecución para la función del activador. Pero aún puede revocar ese privilegio de ejecución después de crear el activador y este no dejará de funcionar. Investigué un poco. Añadiendo enlaces a la pregunta ...
Erwin Brandstetter