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

From Tom Lane
Subject Re: Allowing to create LEAKPROOF functions to non-superuser
Date
Msg-id 341912.1618864356@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing to create LEAKPROOF functions to non-superuser  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Allowing to create LEAKPROOF functions to non-superuser  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Allowing to create LEAKPROOF functions to non-superuser
Next
From: James Coleman
Date:
Subject: Re: "could not find pathkey item to sort" for TPC-DS queries 94-96