Re: row_security GUC does not behave as documented - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: row_security GUC does not behave as documented
Date
Msg-id 20160104033926.GG58441@alvherre.pgsql
Whole thread Raw
In response to Re: row_security GUC does not behave as documented  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: row_security GUC does not behave as documented  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > On Sunday, January 3, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> The fine manual says that when row_security is set to off, "queries fail
> >> which would otherwise apply at least one policy".  However, a look at
> >> check_enable_rls() says that that is a true statement only when the user
> >> is not table owner.  If the user *is* table owner, turning off
> >> row_security seems to amount to just silently disabling RLS, even for
> >> tables with FORCE ROW LEVEL SECURITY.
> >> 
> >> I am not sure if this is a documentation bug or a code bug, but it
> >> sure looks to be one or the other.
> 
> > The original reason for changing how row_security works was to avoid a
> > change in behavior based on a GUC changing. As such, I'm thinking that has
> > to be a code bug, as otherwise it would be a behavior change due to a GUC
> > being changed in the FORCE RLS case for table owners.
> 
> Well, I tried changing the code to act the way I gather it should, and
> it breaks a whole bunch of regression test cases.  See attached.

I think this means we need to postpone 9.5.0 for a week.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: 9.5 BLOCKER: regrole and regnamespace and quotes
Next
From: Tom Lane
Date:
Subject: Re: 9.5 BLOCKER: regrole and regnamespace and quotes