Re: row_security GUC, BYPASSRLS - Mailing list pgsql-hackers

From Robert Haas
Subject Re: row_security GUC, BYPASSRLS
Date
Msg-id CA+TgmoYTfsECYYLZ=FWxUmSVRLxGj41aToxV3hK-4HA+wBU2Vw@mail.gmail.com
Whole thread Raw
In response to Re: row_security GUC, BYPASSRLS  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Thu, Oct 1, 2015 at 11:10 PM, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Sep 28, 2015 at 05:13:56PM -0400, Stephen Frost wrote:
>> * Noah Misch (noah@leadboat.com) wrote:
>> > In schema reviews, I will raise a red flag for use of this feature; the best
>> > designs will instead use additional roles.  I forecast that PostgreSQL would
>> > fare better with no owner-constrained-by-RLS capability.  Even so, others want
>> > it, and FORCE ROW SECURITY would deliver it with an acceptable risk profile.
>>
>> I've attached a patch to implement it.  It's not fully polished but it's
>> sufficient for comment, I believe.  Additional comments, documentation
>> and regression tests are to be added, if we have agreement on the
>> grammer and implementation approach.
>
> This patch has FORCE ROW LEVEL SECURITY take precedence over row_security=off,
> which thwarts pg_dump use of row_security=off to ensure dump completeness.

Yeah, I think that's NOT ok.

> Should this be a table-level flag, or should it be a policy-level flag?  A
> policy-level flag is more powerful.  If nobody really anticipates using that
> power, this table-level flag works for me.

Either works for me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Potential GIN vacuum bug
Next
From: Robert Haas
Date:
Subject: Re: Request for dogfood volunteers (was No Issue Tracker - Say it Ain't So!)