Re: Allowing to create LEAKPROOF functions to non-superuser

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.

regards, tom lane