On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <noah@leadboat.com> 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.
That's not really accurate. You can test the policy first and only
afterwords GRANT access to others.
> 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 can't argue with that, I suppose, but I think row_security=force is
a pretty useful convenience. If we must remove it, so be it, but I'd
be a little sad.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
