Re: [RFC] Interface of Row Level Security - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: [RFC] Interface of Row Level Security
Date
Msg-id 87504E82-A4B0-4AEC-9A5F-12901DF570C5@phlo.org
Whole thread Raw
In response to Re: [RFC] Interface of Row Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [RFC] Interface of Row Level Security
List pgsql-hackers
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.
>> 
>> With RLSBYPASS, all he needs to do is grant one privilege to his
>> replication or backup user. The rest can be left to the development
>> or support team for a specific application.

> 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.

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: No, pg_size_pretty(numeric) was not such a hot idea
Next
From: Tom Lane
Date:
Subject: Re: [RFC] Interface of Row Level Security