Re: Blocking execution of SECURITY INVOKER

Hi,

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
non-viable.

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
SECURITY_RESTRICTED_OPERATION

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
SECURITY_RESTRICTED_OPERATION.

Greetings,

Andres Freund