On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <n...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to