Re: [RFC] Interface of Row Level Security

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alastair Turner <bell(at)ctrlf5(dot)co(dot)za>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Interface of Row Level Security
Date: 2012-05-29 15:14:49
Message-ID: 0A6828AD-687E-4264-8C44-F1C57868E025@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On May29, 2012, at 16:57 , Kohei KaiGai wrote:
> 2012/5/29 Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-29 15:33:59 Re: Function call hierarchy/path since getting the buffer until access its data
Previous Message Robert Haas 2012-05-29 15:13:39 Re: [RFC] Interface of Row Level Security