Re: row_security GUC, BYPASSRLS

On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas wrote:
> On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch <noah(at)leadboat(dot)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.