From 482675987bcdffb390ae735cfd5f34b485ae97c6 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Tue, 4 Apr 2023 12:03:03 -0400 Subject: Add a run_as_owner option to subscriptions. This option is normally false, but can be set to true to obtain the legacy behavior where the subscription runs with the permissions of the subscription owner rather than the permissions of the table owner. The advantages of this mode are (1) it doesn't require that the subscription owner have permission to SET ROLE to each table owner and (2) since no role switching occurs, the SECURITY_RESTRICTED_OPERATION restrictions do not apply. On the downside, it allows any table owner to easily usurp the privileges of the subscription owner - basically, to take over their account. Because that's generally quite undesirable, we don't make this mode the default, but we do make it available, just in case the new behavior causes too many problems for someone. Discussion: http://postgr.es/m/CA+TgmoZ-WEeG6Z14AfH7KhmpX2eFh+tZ0z+vf0=eMDdbda269g@mail.gmail.com --- doc/src/sgml/logical-replication.sgml | 17 +++++++++++++++++ doc/src/sgml/ref/alter_subscription.sgml | 3 ++- doc/src/sgml/ref/create_subscription.sgml | 14 ++++++++++++++ 3 files changed, 33 insertions(+), 1 deletion(-) (limited to 'doc/src') diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml index 90f39676632..c65f4aabfd7 100644 --- a/doc/src/sgml/logical-replication.sgml +++ b/doc/src/sgml/logical-replication.sgml @@ -1785,6 +1785,23 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER SET ROLE to each role that owns a replicated table. + + If the subscription has been configured with + run_as_owner = true, then no user switching will + occur. Instead, all operations will be performed with the permissions + of the subscription owner. In this case, the subscription owner only + needs privileges to SELECT, INSERT, + UPDATE, and DELETE from the + target table, and does not need privileges to SET ROLE + to the table owner. However, this also means that any user who owns + a table into which replication is happening can execute arbitrary code with + the privileges of the subscription owner. For example, they could do this + by simply attaching a trigger to one of the tables which they own. + Because it is usually undesirable to allow one role to freely assume + the privileges of another, this option should be avoided unless user + security within the database is of no concern. + + 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. diff --git a/doc/src/sgml/ref/alter_subscription.sgml b/doc/src/sgml/ref/alter_subscription.sgml index df88e975375..a85e04e4d6d 100644 --- a/doc/src/sgml/ref/alter_subscription.sgml +++ b/doc/src/sgml/ref/alter_subscription.sgml @@ -224,7 +224,8 @@ ALTER SUBSCRIPTION name RENAME TO < binary, streaming, disable_on_error, - password_required, and + password_required, + run_as_owner, and origin. Only a superuser can set password_required = false. diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml index 2e4105d36e9..68aa2b47f2d 100644 --- a/doc/src/sgml/ref/create_subscription.sgml +++ b/doc/src/sgml/ref/create_subscription.sgml @@ -366,6 +366,20 @@ CREATE SUBSCRIPTION subscription_name + + run_as_owner (string) + + + If true, all replication actions are performed as the subscription + owner. If false, replication workers will perform actions on each + table as the owner of that table. The latter configuration is + generally much more secure; for details, see + . + The default is false. + + + + origin (string) -- cgit v1.2.3