On Wed, Mar 1, 2023 at 10:48 AM Stephen Frost <sfr...@snowman.net> wrote: > > Yeah, or any other expressions. Basically impose restrictions when the > > user running the code is not the same as the user who provided the > > code. > > Would this have carve-outs for things like "except if the user providing > the code is trusted/superuser"? Seems like that would be necessary for > the function to be able to do more-or-less anything, but then I worry > that there's superuser-owned code which could leak information or be > used by a malicious owner as that code would still be running as the > invoking user.. Perhaps we could say that the function also has to be > leakproof, but that isn't quite the same issue and therefore it seems > like we'd need to decorate all of the functions with another flag that's > allowed to be run in this manner.
Yes, I think there can be carve-outs based on the relationship of the users involved -- if the user who provided the code is the superuser or some other user who can anyway run whatever they want as the user performing the operation, then there's no point in imposing any restrictions -- and I think there can also be some way of setting policy. I proposed a GUC in an earlier email, and you proposed one with somewhat different semantics in this email, and I'm not sure that either of those things in particular is right or that we ought to be using a GUC for this at all. However, there should almost certainly be SOME way for the superuser to turn any new restrictions off, and there should probably also be some way for an unprivileged user to say "you know, I am totally OK with running any code that alice provides -- just go with it." I don't think we're at a point where we can conclude on what those mechanisms should look like just yet, but I think that everyone who has spoken up agrees that they ought to exist, assuming we go in this direction at all. -- Robert Haas EDB: http://www.enterprisedb.com
