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
