database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-30 21:42:05 +03:00
Code Activity

Make BYPASSRLS behave like superuser RLS bypass.

Browse Source 
Specifically, make its effect independent from the row_security GUC, and
make it affect permission checks pertinent to views the BYPASSRLS role
owns.  The row_security GUC thereby ceases to change successful-query
behavior; it can only make a query fail with an error.  Back-patch to
9.5, where BYPASSRLS was introduced.
This commit is contained in:
Noah Misch
2015-10-03 20:19:57 -04:00
parent cfddb5df5a
commit 01ba7894f3
8 changed files with 44 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/sgml/catalogs.sgml
View File

@ -1454,7 +1454,7 @@
<entry><structfield>rolbypassrls</structfield></entry>
<entry><type>bool</type></entry>
<entry>
Role can bypass row level security policies, see
Role bypasses every row level security policy, see
<xref linkend="ddl-rowsecurity"> for more information.
</entry>
</row>
@ -9385,7 +9385,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<entry><type>bool</type></entry>
<entry></entry>
<entry>
User can bypass row level security policies, see
User bypasses every row level security policy, see
<xref linkend="ddl-rowsecurity"> for more information.
</entry>
</row>
@ -9860,7 +9860,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<entry><structfield>usebypassrls</structfield></entry>
<entry><type>bool</type></entry>
<entry>
User can bypass row level security policies, see
User bypasses every row level security policy, see
<xref linkend="ddl-rowsecurity"> for more information.
</entry>
</row>

25
doc/src/sgml/config.sgml
View File

@ -5537,22 +5537,15 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</term>
<listitem>
<para>
This variable controls if row security policies are to be applied
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. When set to
<literal>off</>, queries will bypass row policies for the table, if
possible, and error if not.
</para>
<para>
For a user who is not a superuser and not the table owner to bypass
row policies for the table, they must have the <literal>BYPASSRLS</>
role attribute. If this is set to <literal>off</> and the user queries
a table which has row policies enabled and the user does not have the
right to bypass row policies then a permission denied error will be
returned.
This variable controls whether to raise an error in lieu of applying a
row security policy. When set to <literal>on</>, policies apply
normally. When set to <literal>off</>, queries fail which would
otherwise apply at least one policy. The default is <literal>on</>.
Change to <literal>off</> where limited row visibility could cause
incorrect results; for example, <application>pg_dump</> makes that
change by default. This variable has no effect on roles which bypass
every row security policy, to wit, superusers and roles with
the <literal>BYPASSRLS</> attribute.
</para>
<para>

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

@ -1543,8 +1543,12 @@ REVOKE ALL ON accounts FROM PUBLIC;
Row security policies can be specific to commands, or to roles, or to
both. The commands available are <literal>ALL</literal>,
<literal>SELECT</>, <literal>INSERT</>, <literal>UPDATE</>, and
<literal>DELETE</>. Multiple roles can be assigned to a given policy
and normal role membership and inheritance rules apply.
<literal>DELETE</>. Multiple roles can be assigned to a given policy and
normal role membership and inheritance rules apply. Table owners,
superusers, and roles with the <literal>BYPASSRLS</> attribute bypass the
row security system when querying a table. Applications that expect to
bypass all row security through those mechanisms should
set <xref linkend="guc-row-security"> to <literal>off</>.
</para>
<para>
@ -1574,17 +1578,6 @@ REVOKE ALL ON accounts FROM PUBLIC;
<xref linkend="sql-altertable"> command.
</para>
<para>
The table owners and superusers bypass the row security system when
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>
Each policy has a name and multiple policies can be defined for a
table. As policies are table-specific, each policy for a table must

9
doc/src/sgml/ref/create_role.sgml
View File

@ -196,16 +196,13 @@ CREATE ROLE <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replac
<term><literal>NOBYPASSRLS</literal></term>
<listitem>
<para>
These clauses determine whether a role is allowed to bypass row-level security (RLS)
policies. A role having the <literal>BYPASSRLS</literal> attribute will
be allowed to bypass row-security policies by setting
<literal>row_security</literal> to
<literal>OFF</literal>. <literal>NOBYPASSRLS</literal> is the default.
These clauses determine whether a role bypasses every row-level
security (RLS) policy. <literal>NOBYPASSRLS</literal> is the default.
Note that pg_dump will set <literal>row_security</literal> to
<literal>OFF</literal> by default, to ensure all contents of a table are
dumped out. If the user running pg_dump does not have appropriate
permissions, an error will be returned. The superuser and owner of the
table being dumped are considered to always have the right to bypass RLS.
table being dumped always bypass RLS.
</para>
</listitem>
</varlistentry>