| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | row_security GUC does not behave as documented |
| Date: | 2016-01-04 00:46:01 |
| Message-ID: | 11108.1451868361@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Meanwhile, there's a statement about row_security in ddl.sgml that is so
vague as to be nearly meaningless, but it doesn't seem to quite match
either of those interpretations. I'm in the midst of copy-editing that
section and will make it match what the code actually does at the moment,
but we'll have to change it again if this is deemed a code bug.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2016-01-04 00:56:56 | Re: Broken lock management in policy.c. |
| Previous Message | Tom Lane | 2016-01-04 00:32:23 | Broken lock management in policy.c. |