Re: Allowing to create LEAKPROOF functions to non-superuser - Mailing list pgsql-hackers

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Apr 19, 2021 at 4:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <noah@leadboat.com> wrote:
> > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
> > >> setting LEAKPROOF.  I would not consult datdba, because datdba currently has
> > >> no special read abilities.  It feels too weird to let BYPASSRLS start
> > >> affecting non-RLS access controls.  A reasonable person may assume that
> > >> BYPASSRLS has no consequences until someone uses CREATE POLICY.  That said, I
> > >> wouldn't be horrified if BYPASSRLS played a part.  BYPASSRLS, like
> > >> pg_read_all_data, clearly isn't something to grant lightly.
> >
> > > I agree that datdba doesn't seem like quite the right thing, but I'm
> > > not sure I agree with the rest. How can we say that leakproof is a
> > > non-RLS access control? Its only purpose is to keep RLS secure, so I
> > > guess I'd be inclined to think that of the two, BYPASSRLS is more
> > > closely related to the topic at hand.
> >
> > Umm ... I'm pretty sure LEAKPROOF also affects optimization around
> > "security barrier" views, which I wouldn't call RLS.  Out of these
> > options, I'd prefer granting the ability to pg_read_all_data.
>
> Oops, I forgot about security_barrier views, which is rather
> embarrassing since I committed them. So, yeah, I agree:
> pg_read_all_data is better.

I'm not really sure that attaching it to pg_read_all_data makes sense..

In general, I've been frustrated by the places where we lump privileges
together rather than having a way to distinctly GRANT capabilities
independently- that's more-or-less exactly what lead me to work on
implementing the role system in the first place, and later the
predefined roles.

I do think it's good to reduce the number of places that require
superuser, in general, but I'm not sure that marking functions as
leakproof as a non-superuser makes sense.

Here's what I'd ask Andrey- what's the actual use-case here?  Are these
cases where users are actually adding new functions which they believe
are leakproof where those functions don't require superuser already to
be created?  Clearly if they're in a untrusted language and you have to
be a superuser to install them in the first place then they should just
mark the function as leakproof when they install it.  If these are
trusted language functions, I'd be curious to actually see them as I
have doubts about if they're actually leakproof..

Or is the actual use-case here that they just want to mark functions we
know aren't leakproof as leakproof anyway because they aren't getting
the performance they want?

If it's the latter, as I suspect it is, then I don't really think the
use-case justifies any change on our part- the right answer is to make
those functions actually leakproof, or write ones which are.

Thanks,

Stephen