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

From Stephen Frost
Subject Re: Multi-tenancy with RLS
Date
Msg-id 20160115162159.GX3685@tamriel.snowman.net
Whole thread Raw
In response to Re: Multi-tenancy with RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Multi-tenancy with RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Joe Conway <mail@joeconway.com> writes:
> > 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.

Right, that's what this patch set is about.

> 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.

Personally, I like the idea of the capability, but I also agree that
it'd be a great deal more challenging to do and would require a lot of
pretty invasive and scary changes.  Hence, my thinking was that we'd
define our own set of policies which mimic what we already do through
the permissions system (thus, only impacting SQL queries against the
catalog and not anything about how the backend accesses the catalogs).

I'm on the fence about if we'd allow those policies to be modified by
users or not.

> 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 don't follow how this would destroy the ability to run pg_dump.
Ideally, we'd have a result where a user could run pg_dump without
having to apply any filters of their own and they'd get a dump of all
objects they're allowed to see.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Benedikt Grundmann
Date:
Subject: Re: Death by regexp_replace
Next
From: Tom Lane
Date:
Subject: Re: Death by regexp_replace