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