Re: Allowing to create LEAKPROOF functions to non-superuser

On Mon, Apr 19, 2021 at 4:32 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <noah(at)leadboat(dot)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