On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch <noah@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
