Re: [RFC] Interface of Row Level Security

On Tue, May 29, 2012 at 9:12 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On May29, 2012, at 13:37 , Kohei KaiGai wrote:
>> 2012/5/27 Alastair Turner <bell(at)ctrlf5(dot)co(dot)za>:
>>> Excerpts from Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote on Fri, May 25,
>>> 2012 at 11:08 PM:
>>>> If we assume RLS is applied when user has
>>>> no privileges on tables, the current ExecCheckRTEPerms()
>>>> always raises an error towards unprivileged users, prior to
>>>> execution of queries.
>>>> Isn't it preferable behavior to allow unprivileged users to
>>>> reference a table (or columns) when it has RLS policy?
>
> I don't think so. Per-table and per-column permission checks should still
> apply independent from any RLS policy. You can always grant SELECT access
> to PUBLIC if want to rely solely on the RLS policy...

I strongly agree with this. Permissions checks should be applied
first, so that we can boot anyone who has no business being there at
all as early in the process as possible. As a second step, if you
have a right to the query the table, row-level security should
intervene to control which rows you can see.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company