On Wed, Dec 18, 2013 at 10:21 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> My main worry was that it requires the user to build everything
> manually, and is potentially error prone as a result. To address that we
> can build convenience features (label security, ACL types and operators,
> etc) on top of the same infrastructure later - it doesn't have to go in
> right away.
>
> So putting that side, the concerns I have are:
>
> - The current RLS design is restricted to one predicate per table with
> no contextual control over when that predicate applies. That means we
> can't implement anything like "policy groups" or overlapping sets of
> predicates, anything like that has to be built by the user. We don't
> need multiple predicates to start with but I want to make sure there's
> room for them later, particularly so that different apps / extensions
> that use row-security don't have to fight with each other.
>
> - You can't declare a predicate then apply it to a bunch of tables with
> consistent security columns. Updating/changing predicates will be a
> pain. We might be able to get around that by recommending that people
> use an inlineable SQL function to declare their predicates, but
> "inlineable" can be hard to pin down sometimes. If not, we need
> something akin to GRANT ... ALL TABLES IN SCHEMA ... for row security,
> and ALTER DEFAULT PRIVILEGES ... too.
>
> - It's too hard to see what tables have row-security and what impact it
> has. Needs psql improvements.
>
> - There's no way to control whether or not a client can see the
> row-security policy definition.
>
>
> The other one I want to deal with is secure session variables, but
> that's mostly a performance optimisation we can add later.
>
> What's your list?
I don't have a lot of specific concerns apart from what I mentioned here:
http://www.postgresql.org/message-id/CA+TgmoYC37qWNQkKQx3P3GU3Psfh3Tcox8uE06nnUiqn_4RAqA@mail.gmail.com
One thing we do need to think about is our good friend search_path,
and making sure that it's relatively easy to implement RLS in a way
that's secure against malicious manipulation thereof.
I do also agree with some of your concerns, particularly the first two
("is it too manual?" and "insufficient contextual control").
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
