| 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 01:10:08 |
| Message-ID: | CAOuzzgrsE=KrYnacfPRTKf0uXJjNtEoTgspu6yP4DtYU-SL+Pw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom,
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.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2016-01-04 01:16:14 | Re: Broken lock management in policy.c. |
| Previous Message | Peter Geoghegan | 2016-01-04 01:00:59 | Re: Broken lock management in policy.c. |