On Wed, Mar 1, 2023 at 10:48 AM Stephen Frost <sfrost@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
