database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Adjust behavior of row_security GUC to match the docs.

Browse Source 
Some time back we agreed that row_security=off should not be a way to
bypass RLS entirely, but only a way to get an error if it was being
applied.  However, the code failed to act that way for table owners.
Per discussion, this is a must-fix bug for 9.5.0.

Adjust the logic in rls.c to behave as expected; also, modify the
error message to be more consistent with the new interpretation.
The regression tests need minor corrections as well.  Also update
the comments about row_security in ddl.sgml to be correct.  (The
official description of the GUC in config.sgml is already correct.)

I failed to resist the temptation to do some other very minor
cleanup as well, such as getting rid of a duplicate extern declaration.
This commit is contained in:
Tom Lane
2016-01-04 12:21:31 -05:00
parent 8978eb03a8
commit 5d35438273
4 changed files with 78 additions and 92 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
doc/src/sgml/ddl.sgml
View File

@ -1572,11 +1572,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
bypass the row security system when accessing a table. Table owners
normally bypass row security as well, though a table owner can choose to
be subject to row security with <link linkend="sql-altertable">ALTER
TABLE ... FORCE ROW LEVEL SECURITY</>. Even in a table with that option
selected, the table owner will bypass row security if the
<xref linkend="guc-row-security"> configuration parameter is set
to <literal>off</>; this setting is typically used for purposes such as
backup and restore.
TABLE ... FORCE ROW LEVEL SECURITY</>.
</para>
<para>
@ -1606,14 +1602,6 @@ REVOKE ALL ON accounts FROM PUBLIC;
of all roles that they are a member of.
</para>
<para>
Referential integrity checks, such as unique or primary key constraints
and foreign key references, always bypass row security to ensure that
data integrity is maintained. Care must be taken when developing
schemas and row level policies to avoid <quote>covert channel</> leaks of
information through such referential integrity checks.
</para>
<para>
As a simple example, here is how to create a policy on
the <literal>account</> relation to allow only members of
@ -1773,6 +1761,26 @@ postgres=&gt; update passwd set pwhash = 'abc';
UPDATE 1
</programlisting>
<para>
Referential integrity checks, such as unique or primary key constraints
and foreign key references, always bypass row security to ensure that
data integrity is maintained. Care must be taken when developing
schemas and row level policies to avoid <quote>covert channel</> leaks of
information through such referential integrity checks.
</para>
<para>
In some contexts it is important to be sure that row security is
not being applied. For example, when taking a backup, it could be
disastrous if row security silently caused some rows to be omitted
from the backup. In such a situation, you can set the
<xref linkend="guc-row-security"> configuration parameter
to <literal>off</>. This does not in itself bypass row security;
what it does is throw an error if any query's results would get filtered
by a policy. The reason for the error can then be investigated and
fixed.
</para>
<para>
For additional details see <xref linkend="sql-createpolicy">
and <xref linkend="sql-altertable">.