Re: row_security GUC, BYPASSRLS

Noah Misch <noah@leadboat.com> writes:
> On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas 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.  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 have to say I'm with Noah on this.  I do not think we should create
potential security holes to help users with uncooperative DBAs.  Those
users have got problems far worse than whether they can test their RLS
policies; or in other words, what in God's name are you doing storing
sensitive data in a system with a hostile DBA?
        regards, tom lane