Make BYPASSRLS behave like superuser RLS bypass.

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.

4 files changed, 21 insertions, 38 deletions

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index ec6badbc311..4a75b5f33d4 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -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>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index c8ec219ffc6..5e43de9bbdd 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -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>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index a796f6c906d..fe5a076fe12 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -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>
@@ -1575,17 +1579,6 @@ REVOKE ALL ON accounts FROM PUBLIC;
   </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
    have a unique name.  Different tables may have policies with the
diff --git a/doc/src/sgml/ref/create_role.sgml b/doc/src/sgml/ref/create_role.sgml
index f4a176bff3f..240c21ce85f 100644
--- a/doc/src/sgml/ref/create_role.sgml
+++ b/doc/src/sgml/ref/create_role.sgml
@@ -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>