database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-31 22:04:40 +03:00
Code Activity

Respect permissions within logical replication.

Browse Source 
Prevent logical replication workers from performing insert, update,
delete, truncate, or copy commands on tables unless the subscription
owner has permission to do so.

Prevent subscription owners from circumventing row-level security by
forbidding replication into tables with row-level security policies
which the subscription owner is subject to, without regard to whether
the policy would ordinarily allow the INSERT, UPDATE, DELETE or
TRUNCATE which is being replicated.  This seems sufficient for now, as
superusers, roles with bypassrls, and target table owners should still
be able to replicate despite RLS policies.  We can revisit the
question of applying row-level security policies on a per-row basis if
this restriction proves too severe in practice.

Author: Mark Dilger
Reviewed-by: Jeff Davis, Andrew Dunstan, Ronan Dunklau
Discussion: https://postgr.es/m/9DFC88D3-1300-4DE8-ACBC-4CEF84399A53%40enterprisedb.com
This commit is contained in:
Jeff Davis
2022-01-07 17:38:20 -08:00
parent d0d62262d3
commit a2ab9c06ea
6 changed files with 499 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
doc/src/sgml/logical-replication.sgml
View File

@ -330,6 +330,19 @@
will simply be skipped.
</para>
<para>
Logical replication operations are performed with the privileges of the role
which owns the subscription. Permissions failures on target tables will
cause replication conflicts, as will enabled
<link linkend="ddl-rowsecurity">row-level security</link> on target tables
that the subscription owner is subject to, without regard to whether any
policy would ordinary reject the <command>INSERT</command>,
<command>UPDATE</command>, <command>DELETE</command> or
<command>TRUNCATE</command> which is being replicated. This restriction on
row-level security may be lifted in a future version of
<productname>PostgreSQL</productname>.
</para>
<para>
A conflict will produce an error and will stop the replication; it must be
resolved manually by the user. Details about the conflict can be found in
@ -337,7 +350,7 @@
</para>
<para>
The resolution can be done either by changing data on the subscriber so
The resolution can be done either by changing data or permissions on the subscriber so
that it does not conflict with the incoming change or by skipping the
transaction that conflicts with the existing data. The transaction can be
skipped by calling the <link linkend="pg-replication-origin-advance">
@ -530,9 +543,9 @@
<para>
A user able to modify the schema of subscriber-side tables can execute
arbitrary code as a superuser. Limit ownership
and <literal>TRIGGER</literal> privilege on such tables to roles that
superusers trust. Moreover, if untrusted users can create tables, use only
arbitrary code as the role which owns any subscription which modifies those tables. Limit ownership
and <literal>TRIGGER</literal> privilege on such tables to trusted roles.
Moreover, if untrusted users can create tables, use only
publications that list tables explicitly. That is to say, create a
subscription <literal>FOR ALL TABLES</literal> or
<literal>FOR ALL TABLES IN SCHEMA</literal> only when superusers trust
@ -576,13 +589,20 @@
<para>
The subscription apply process will run in the local database with the
privileges of a superuser.
privileges of the subscription owner.
</para>
<para>
Privileges are only checked once at the start of a replication connection.
They are not re-checked as each change record is read from the publisher,
nor are they re-checked for each change when applied.
On the publisher, privileges are only checked once at the start of a
replication connection and are not re-checked as each change record is read.
</para>
<para>
On the subscriber, the subscription owner's privileges are re-checked for
each transaction when applied. If a worker is in the process of applying a
transaction when the ownership of the subscription is changed by a
concurrent transaction, the application of the current transaction will
continue under the old owner's privileges.
</para>
</sect1>