Hi,
On 2023-02-28 12:36:38 -0800, Jeff Davis wrote:
> On Tue, 2023-02-28 at 11:28 -0800, Andres Freund wrote:
> > I can only repeat myself in stating that SECURITY DEFINER solves none
> > of the
> > relevant issues. I included several examples of why it doesn't in the
> > recent
> > thread about "blocking SECURITY INVOKER". E.g. that default arguments
> > of
> > SECDEF functions are evaluated with the current user's privileges,
> > not the
> > function owner's privs:
> >
> > https://postgr.es/m/20230113032943.iyxdu7bnxe4cmbld%40awork3.anarazel.de
>
> I was speaking a bit loosely, using "SECURITY DEFINER" to mean the
> semantics of executing code as the one who wrote it. I didn't
> specifically mean the function marker, because as you pointed out in
> the other thread, that's not enough.
Oh, ok.
> From your email it looks like there is still a path forward:
>
> "The proposal to not trust any expressions controlled by untrusted
> users at least allows to prevent execution of code, even if it doesn't
> provide a way to execute the code in a safe manner. Given that we
> don't have the former, it seems foolish to shoot for the latter."
>
> And later:
>
> "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"
>
> My takeaway from that thread was that we need a mechanism to deal with
> non-function code (e.g. default expressions) first; but once we have
> that, it opens up the design space to better solutions or at least
> mitigations. Is that right?
I doubt it's realistic to change the user for all kinds of expressions
individually. A query can involve expressions controlled by many users,
changing the current user in a super granular way seems undesirable from a
performance and complexity pov.
Greetings,
Andres Freund
