Re: row security roadmap proposal

On Wed, Dec 18, 2013 at 3:30 AM, Craig Ringer <craig(at)2ndquadrant(dot)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