From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: row_security GUC does not behave as documented |
Date: | 2016-01-04 03:56:49 |
Message-ID: | 20160104035649.GS3685@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > On Sunday, January 3, 2016, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
Right, I wrote the code that way originally thinking that it didn't make
sense to throw a permission denied error when it's the owner, but I
hadn't been thinking about, at that time, how we don't want the GUC to
result in a behavior change.
As we don't want to end up with the same behavior-change-due-to-GUC that
we had with the original row_security implementation, we should change
the code as your patch does and update the regression tests accordingly.
Perhaps the error code thrown could be tailored a bit when it's the
owner, to indicate that FORCE RLS has been set on the table, but I'm not
sure it's really a big deal either way.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-01-04 04:04:08 | Re: row_security GUC does not behave as documented |
Previous Message | Tom Lane | 2016-01-04 03:52:04 | Re: row_security GUC does not behave as documented |