2012/6/5 Tom Lane <t...@sss.pgh.pa.us>: > Florian Pflug <f...@phlo.org> writes: >> On Jun4, 2012, at 18:38 , Kohei KaiGai wrote: >>> 2012/6/4 Florian Pflug <f...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
