From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: row_security GUC, BYPASSRLS |
Date: | 2015-09-15 16:28:38 |
Message-ID: | 55F84736.5080909@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/15/2015 11:10 AM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>>> 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.
>
> Keep in mind that if you have an uncooperative DBA on your production
> system, you can always test your policy to your heart's content on a
> playpen installation. In fact, most people would consider that good
> engineering practice anyway, rather than pushing untested code directly
> into production.
That's exactly right. We should provide flexibility for testing in test
environments, and also the ability to lock things down tight in production.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-09-15 16:36:05 | Re: cache type info in json_agg and friends |
Previous Message | Joe Conway | 2015-09-15 16:23:49 | Re: row_security GUC, BYPASSRLS |