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.
> 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...
best regards,
Florian Pflug
