Re: Multi-tenancy with RLS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Multi-tenancy with RLS
Date
Msg-id 10864.1452188359@sss.pgh.pa.us
Whole thread Raw
In response to Re: Multi-tenancy with RLS  (Joe Conway <mail@joeconway.com>)
Responses Re: Multi-tenancy with RLS  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> On 01/06/2016 12:15 PM, Robert Haas wrote:
>> Is any committer thinking about taking a serious look at this patch series?
>> 
>> I ask because (1) it seems like it could be nice to have but (2) it
>> frightens me terribly.  We are generally very sparing about assuming
>> that "stuff" (triggers, partial indexes, etc.) that works for user
>> tables can also be made to work for system tables.  I haven't thought
>> deeply about what might go wrong in this particular case, but it
>> strikes me that if Haribabu Kommi is building something that is doomed
>> for some reason, it would be good to figure that out before he spends
>> any more time on it than he already has.

> As Stephen mentioned, yes, I am very interested in at least some aspects
> of this patch. The ability to apply RLS to system tables could be useful
> to solve a number of problems we don't have a good story for today,
> multi-tenancy only being one of them.

FWIW, it seems offhand like we might not have that much trouble with
applying RLS to system catalogs as long as it's understood that RLS
only has anything to do with SQL queries issued against the catalogs.

If we imagine that RLS should somehow filter a backend's own operations on
the catalogs, then I agree with Robert that the entire thing is deeply
scary and probably incapable of being made to work robustly.

However, by "not that much trouble" I only mean getting an implementation
that works and doesn't create more security problems than it fixes.
Usability is still likely to be a huge problem.  In particular it seems
likely that any attempt to actually put RLS policies on the catalogs would
completely destroy the ability to run pg_dump except as a BYPASSRLS role.
That would be an unpleasant consequence.

I've not read the patch set, so maybe it contains some ideas about how
to mitigate the usability issues, in which case never mind ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jarred Ward
Date:
Subject: Re: pglogical_output - a general purpose logical decoding output plugin
Next
From: Jim Nasby
Date:
Subject: Re: Very confusing installcheck behavior with PGXS