Re: Multi-tenancy with RLS

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Multi-tenancy with RLS
Дата
Msg-id 10864.1452188359@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Multi-tenancy with RLS  (Joe Conway <mail@joeconway.com>)
Ответы Re: Multi-tenancy with RLS  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Jarred Ward
Дата:
Сообщение: Re: pglogical_output - a general purpose logical decoding output plugin
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Very confusing installcheck behavior with PGXS