On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch <n...@leadboat.com> wrote: > SECURITY DEFINER execution blocks SET ROLE, SET SESSION AUTHORIZATION, and > sometimes "GRANT role1 TO role2". Otherwise, it works like regular execution. > Adding exceptions, particularly silent behavior changes as opposed to hard > errors, is a big deal.
Yeah, that does seem possibly surprising... > 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. ...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. -- 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
