On Wed, Dec 18, 2013 at 10:21 PM, Craig Ringer <cr...@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_4r...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers