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.
regards, tom lane