Re: [RFC] Interface of Row Level Security

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: [RFC] Interface of Row Level Security
Дата
Msg-id 0A6828AD-687E-4264-8C44-F1C57868E025@phlo.org
обсуждение исходный текст
Ответ на Re: [RFC] Interface of Row Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
On May29, 2012, at 16:57 , Kohei KaiGai wrote:
> 2012/5/29 Robert Haas <robertmhaas@gmail.com>:
>> One idea might be to have a grantable permission that permits the RLS
>> policy to be bypassed.  So, if a user has only SELECT permission, they
>> can select from the table, but the RLS policy will apply.  If they
>> have both SELECT and RLSBYPASS (probably not what we really want to
>> call it) permission, then they can select from the table and the RLS
>> policy will be skipped.  This means that superusers automatically skip
>> all RLS policies (which seems right) and table owners skip them by
>> default (but could revoke their own privileges) and other people can
>> skip them if the table owner (or the superuser) grants them the
>> appropriate privilege on the table involved.

> Isn't it unavailable to describe using RLS policy?
> In case when 'alice' and 'bob' should bypass RLS policy on a certain table,
> we will be able to describe it as follows:
>    (current_user in ('alice', 'bob') OR rls_policy_this_table(X, Y, Z))
>
> I have one concern the "current_user in (...)" is not wiped out at the planner
> stage, although its evaluation result is obvious prior to execution.

I think you'd simply pretend the RLS policy isn't there (i.e., don't rewrite
the table reference into a sub-query) if the user has the RLSBYPASS privilege,
not add another clause which selectively neuters the RLS policy.

Wait a moment.. now I get it.

You're saying that Robert's RLSBYPASS privilege is redundant, since one can
always add a "current_user IN ..." clause to the RLS policy function. That might
be the case theoretically, but I still believe that Robert's suggestion has a
lot of benefits. First, due to role inheritance, a simply clause like the above
isn't sufficient. Second, it doesn't make superusers and table owner bypass
RLS by default. Which I think is a good idea (bypassing by default, that is),
because it prevents broken backups (for those using pg_dump) and data exports.
It doesn't cost anything in terms of security, because those users could disable
the RLS policy away if they are so inclined.

best regards,
Florian Pflug



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [RFC] Interface of Row Level Security
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Function call hierarchy/path since getting the buffer until access its data