2012/6/5 Tom Lane <tgl@sss.pgh.pa.us>:
> Florian Pflug <fgp@phlo.org> writes:
>> On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
>>> 2012/6/4 Florian Pflug <fgp@phlo.org>:
>>>> Without something like RLSBYPASS, the DBA needs to have intimate
>>>> knowledge about the different RLS policies to e.g. guarantee that his
>>>> backups aren't missing crucial information, or that the replication
>>>> system indeed replicates all rows.
>
>>> It seems to me you can define a function which implements site-
>>> specific security requirement (E.g "backup should not be prevented
>>> by RLS policy"), then include it as a part of RLS policy
>>> (or implicitly added by extensions, like sepgsql tries to do).
>
>> Sure. But that requires each and every application which uses RLS
>> to provide support for special backup (or replication, or whatever)
>> privileges. And it requires the DBA to know how to assign these
>> privileges to certain roles for each any every application in question.
>> For shops which uses a lot of different applications, all with their
>> own RLS policy, that can quickly get out of hand.
>
>> Plus, a bug in one of these RLS policies has the potential to render
>> backups incomplete.
>
> I agree with Florian here: if there is no way to disable RLS for
> backups, the database will be un-administratable. RLSBYPASS is not
> necessarily the only or best way to provide such an override, but we
> have to have something that is simple, foolproof, and *not* dependent
> on the details of any one RLS policy.
>
> 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.
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.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
