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

Remove the row_security=force GUC value.

Every query of a single ENABLE ROW SECURITY table has two meanings, with
the row_security GUC selecting between them.  With row_security=force
available, every function author would have been advised to either set
the GUC locally or test both meanings.  Non-compliance would have
threatened reliability and, for SECURITY DEFINER functions, security.
Authors already face an obligation to account for search_path, and we
should not mimic that example.  With this change, only BYPASSRLS roles
need exercise the aforementioned care.  Back-patch to 9.5, where the
row_security GUC was introduced.

Since this narrows the domain of pg_db_role_setting.setconfig and
pg_proc.proconfig, one might bump catversion.  A row_security=force
setting in one of those columns will elicit a clear message, so don't.
This commit is contained in:
Noah Misch
2015-09-20 20:45:41 -04:00
parent 8346218c02
commit 537bd178c7
8 changed files with 34 additions and 241 deletions

View File

@ -5549,10 +5549,8 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
to queries which are run against tables that have row security enabled.
The default is <literal>on</>. When set to <literal>on</>, all users,
except superusers and the owner of the table, will have the row
policies for the table applied to their queries. The table owner and
superuser can request that row policies be applied to their queries by
setting this to <literal>force</>. Lastly, this can also be set to
<literal>off</> which will bypass row policies for the table, if
policies for the table applied to their queries. When set to
<literal>off</>, queries will bypass row policies for the table, if
possible, and error if not.
</para>
@ -5565,13 +5563,6 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
returned.
</para>
<para>
The allowed values of <varname>row_security</> are
<literal>on</> (apply normally - not to superuser or table owner),
<literal>off</> (fail if row security would be applied), and
<literal>force</> (apply always - even to superuser and table owner).
</para>
<para>
For more information on row security policies,
see <xref linkend="SQL-CREATEPOLICY">.

View File

@ -1585,16 +1585,13 @@ REVOKE ALL ON accounts FROM PUBLIC;
<para>
The table owners and superusers bypass the row security system when
querying a table, by default. Row security can be enabled for
superusers and table owners by setting
<xref linkend="guc-row-security"> to <literal>force</literal>. Any
user can request that row security be bypassed by setting
<xref linkend="guc-row-security"> to <literal>off</literal>. If
the user does not have privileges to bypass row security when
querying a given table then an error will be returned instead. Other
users can be granted the ability to bypass the row security system
with the <literal>BYPASSRLS</literal> role attribute. This
attribute can only be set by a superuser.
querying a table. Any user can request that row security be bypassed by
setting <xref linkend="guc-row-security"> to <literal>off</literal>. If
the user does not have privileges to bypass row security when querying a
given table then an error will be returned instead. Other users can be
granted the ability to bypass the row security system with
the <literal>BYPASSRLS</literal> role attribute. This attribute can only
be set by a superuser.
</para>
<para>