On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote:
> On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> > I doubt that falsely labeling a function LEAKPROOF can get you more
> > than the ability to read data you're not supposed to be able to read
> > ... but that ability is then available to all users, or at least all
> > users who can execute the function in question. So it definitely is a
> > fairly serious security hazard, and one that's not well modeled by
> > role labels. If you give somebody e.g. pg_read_all_data privileges,
> > you don't expect that that means they can give it to other users.
I do expect that, essentially. Like Andres describes for BYPASSRLS, they can
create and GRANT a SECURITY DEFINER function that performs an arbitrary query
and returns a refcursor (or stores the data to a table of the caller's
choosing, etc.). Unlike BYPASSRLS, they can even make pg_read_all_data own
the function, making the situation persist after one drops the actor's role
and that role's objects.
> A user with BYPASSRLS can create public security definer functions
> returning data. If the concern is a BYPASSRLS user intentionally
> exposing data, then there's not a meaningful increase to allow defining
> LEAKPROOF functions.
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.
