Quais são os privilégios necessários para executar uma função de trigger no PostgreSQL 8.4?

Parece que os privilégios definidos para uma função não importam para executar uma função de gatilho. Acho que vi algum dia que os privilégios necessários para executar uma função de gatilho são o privilégio EXECUTE, mas para o proprietário da tabela, não a função real que executa a ação que dispara o gatilho que chama a função de gatilho.

Não consigo encontrar a parte da documentação que explica esse ponto, alguma ajuda?

— Erwin Brandstetter
fonte

As funções de gatilho se comportam como outras funções no que diz respeito aos privilégios. Com uma pequena exceção:

Para criar um gatilho em uma tabela, o usuário deve ter o TRIGGER privilégio na tabela. O usuário também deve ter EXECUTEprivilégio na função de disparo.

ATUALIZAÇÃO Após o feedback nos comentários, fiz algumas pesquisas. Há um item TODO aberto no Postgres Wiki:

Aperte as verificações de permissão do acionador

Vinculado a esta discussão nos hackers do Postgres . Atualmente, os EXECUTEprivilégios em uma função de acionamento são verificados apenas no momento da criação do acionador , mas não no tempo de execução. Portanto, revogar EXECUTE na função de gatilho não tem efeito em um gatilho depois de criado. Sua observação parece estar correta.

Isso não concede privilégios adicionais para manipular objetos. Se a função de chamada não possuir privilégios necessários para executar (partes do) corpo da função, a exceção usual será gerada. Para pavimentar o caminho, você pode tornar um usuário privilegiado OWNERda função e usar o

SECURITY DEFINER

, conforme documentado no manual aqui . Faz com que a função seja executada com as permissões do proprietário, em vez do invocador (padrão).

Se o proprietário é um superusuário, você precisa ter cuidado extra com quem você concede o EXECUTEprivilégio e o que a função pode fazer para evitar abusos. Você pode querer

REVOKE ALL ON FUNCTION foo() FROM public;

para começar e usar SET search_pathpara a função.
Certifique-se de ler o capítulo Escrevendo SECURITY DEFINERfunções com segurança .

Encontre um exemplo de código nesta resposta relacionada no SO.

— Erwin Brandstetter
fonte

Não, eu não quero um SECURITY DEFINER, eu quero um SECURITY INVOKER. Mas parece (para a função de disparo, não para a função regular) que, usando a opção padrão ( SECURITY INVOKER), ela não age dessa maneira.

@ EtienneRouxel: funções de trigger são funções como outras funções no que diz respeito a privilégios. O que faz você pensar o contrário?

— Erwin Brandstetter

@ EtienneRouxel: adicionei uma cotação no manual para documentar uma pequena exceção.

— Erwin Brandstetter

Teste: eu criei uma função de gatilho simples que gera a NOTICE. Eu removi ALLprivilégios de PUBLICe para o proprietário da função. Então, se eu usar o proprietário ou qualquer outra função que não tenha nenhum privilégio nessa função, esperarei um erro devido à falta de privilégios, mas tudo será executado com êxito.

@ EtienneRouxel: Interessante. Eu também testei. Você não pode criar o gatilho se não tiver o privilégio de execução da função de gatilho. Mas você ainda pode revogar esse privilégio de execução depois de criar o gatilho e o gatilho não para de funcionar. Eu fiz algumas pesquisas. Adicionando links para a questão ...

— Erwin Brandstetter