Joe Conway <m...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers