Re: [RFC] Interface of Row Level Security

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, 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 14:57:15
Message-ID: CADyhKSWYWGfk7+s6Zc8CP_m37RwHJiE3VUEpPJ1D2ok6v64QaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-29 15:12:05 Re: [RFC] Interface of Row Level Security
Previous Message Florian Pflug 2012-05-29 14:44:43 Re: [RFC] Interface of Row Level Security