2012/6/5 Florian Pflug <fgp@phlo.org>:
> On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
>> 2012/6/5 Tom Lane <tgl@sss.pgh.pa.us>:
>>> I suspect that KaiGai-san's objection basically comes down to not
>>> wanting to have what amounts to a backdoor in RLS policies. However,
>>> what Florian is saying is that you have to have a backdoor anyway,
>>> unless you'd like to be at risk of losing data because it wasn't
>>> backed up. You can either have one well-understood, well-documented,
>>> well-tested backdoor, or you can have an ad-hoc backdoor in each RLS
>>> policy. Nobody can think that the latter approach is preferable.
>
>> At least, database superusers shall bypass the RLS policy; it is a well
>> understandable behavior and an approach to minimize the back-door;
>> and allows to get complete database backup.
>
> I don't think we want to force people to run stuff with superuser
> privileges just for the sake of bypassing a RLS policy. On the whole,
> that reduces the overall security, not adds to it.
>
I can understand your opinion. But I'm still uncertain whether the new
permission is the best idea we can offer...
>> It is easy to add a special privilege mechanism to bypass RLS policy
>> later, however, not easy in opposite side. It seems to me a reasonable
>> start-up to allow only superusers to bypass RLS policy.
>
> What's to be gained by that? Once there's *any* way to bypass a RLS
> policy, you'll have to deal with the plan invalidation issues you
> mentioned anyway. ISTM that complexity-wide, you don't save much by not
> having RLSBYPASS (or something similar), but feature-wise you lose at
> lot...
>
All we need to change is selection of the function to be appended
automatically. In case when superusers are allowed to bypass RLS
policy, "OR has_superuser_privilege()" shall be appended to the
user given clause, however, "OR has_table_privilege()" shall be
appended instead in case of RLSBYPASS permission.
(Note that has_table_privilege() always true for superusers.)
I think it does not require to add a mechanism to invalidate
prepared-statement, because all the checks are applied on
executor stage. And these functions can be stable functions,
so I believe some enhancements at planner will correctly wipe
out prior to query execution at the next step.
Conditional RLS policy in planner stage seems to me problematic
so I don't want to include this feature on the first version.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
