Re: Allowing to create LEAKPROOF functions to non-superuser

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.

-- 
Robert Haas
EDB: http://www.enterprisedb.com