Re: Allowing to create LEAKPROOF functions to non-superuser

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.

            regards, tom lane