Re: row security roadmap proposal - Mailing list pgsql-hackers

From Robert Haas
Subject Re: row security roadmap proposal
Date
Msg-id CA+TgmoYE7bERYK5mRQoZ+cyMnk5Evgc7Pn-saL0+DfZbcSu93w@mail.gmail.com
Whole thread Raw
In response to Re: row security roadmap proposal  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: row security roadmap proposal
List pgsql-hackers
On Wed, Dec 18, 2013 at 3:30 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> In my view the proposed patch doesn't offer a significant improvement in
> declarative security, beyond what we can get by just adding update
> support to s.b. views and using search_path to control whether a user
> sees the view or the base table.
>
> It's a lot like Oracle Virtual Private Database (VPD): A set of low
> level building blocks you can build your own flexible row security model
> with. One where you have to very carefully write security-sensitive
> predicates and define all your security model tables, etc yourself.
>
> That's why I'm now of the opinion that we should make it possible to
> achieve the same thing with s.b. views and the search_path (by adding
> update support)... then build a declarative row-security system that
> doesn't require the user fiddling with delicate queries and sensitive
> scripts on top of that.

To be clear, I wasn't advocating for a declarative approach; I think
predicates are fine.  There are usability issues to worry about either
way, and my concern is that we address those.  A declarative approach
would certainly be valuable in that, for those people for whom it is
sufficiently flexible, it's probably quite a lot easier than writing
predicates.  But I fear that some people will want a lot more
generality than a label-based system can accommodate.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: row security roadmap proposal
Next
From: Robert Haas
Date:
Subject: Re: Logging WAL when updating hintbit