Re: Blocking execution of SECURITY INVOKER

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Blocking execution of SECURITY INVOKER
Date: 2023-01-13 18:30:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2023-01-13 10:04:19 -0800, Jeff Davis wrote:
> However, the normal use case for expressions (whether in a default
> expression or check constraint or whatever) is very simple and doesn't
> even involve table access. There must be a way to satisfy those simple
> cases without opening up a vast attack surface area, and if we do, then
> I think my proposal might look useful again.

I don't see how. I guess we could try to introduce a classification of "never
dangerous" functions (and thus operators). But that seems like a crapton of
work and hard to get right. And I think my examples pretty conclusively show
that security definer isn't a useful boundary to *reduce* privileges. So the
whole idea of preventing only security invoker functions just seems

I think the combination of
a) a setting that restricts evaluation of any non-trusted expressions,
independent of the origin
b) an easy way to execute arbitrary statements within

is promising though. In later steps We might be able to use a) to offer the
option to automatically switch to expression owners in specific places (if the
current user has the rights to do that).

An alternative to b would be a version SET ROLE that can't be undone. But I
think we'd just miss all the other things that are prevented by


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-13 18:37:46 Re: Generate pg_stat_get_xact*() functions with Macros
Previous Message Andrey Borodin 2023-01-13 18:15:56 Re: Transaction timeout