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:
@ -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">.
|
||||
|
@ -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>
|
||||
|
Reference in New Issue
Block a user