On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas wrote: > On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch <n...@leadboat.com> wrote: > > Pondering it afresh this week, I see now that row_security=force itself is > > the > > problem. It's a new instance of the maligned "behavior-changing GUC". > > Function authors will not consistently test the row_security=force case, and > > others can run the functions under row_security=force and get novel results. > > This poses a reliability and security threat. While row_security=force is > > handy for testing, visiting a second role for testing purposes is a fine > > replacement. Let's remove "force", making row_security a config_bool. If > > someone later desires to revive the capability, a DDL-specified property of > > each policy would be free from these problems.
[A variation on that idea is "ALTER TABLE foo FORCE ROW LEVEL SECURITY", affecting all policies of one table rather than individual policies.] > ...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. 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
