On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <n...@leadboat.com> wrote: >> ...but I'm not sure I like this, either. Without row_security=force, >> it's hard for a table owner to test their policy, unless they have the >> ability to assume some other user ID, which some won't. If someone >> puts in place a policy which they believe secures their data properly >> but which actually does not, and they are unable to test it properly >> for lack of this setting, that too will be a security hole. We will >> be able to attribute it to user error rather than product defect, but >> that will be cold comfort to the person whose sensitive data has been >> leaked. > > The testing capability is nice, all else being equal. Your scenario entails a > data custodian wishing to test with row_security=force but willing to entrust > sensitive data to an untested policy.
That's not really accurate. You can test the policy first and only afterwords GRANT access to others. > It also requires a DBA unwilling to > furnish test accounts to custodians of sensitive data. With or without > row_security=force, such a team is on the outer perimeter of the audience able > to benefit from RLS. Nonetheless, I'd welcome a replacement test aid. I can't argue with that, I suppose, but I think row_security=force is a pretty useful convenience. If we must remove it, so be it, but I'd be a little sad. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers