Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Non-superuser subscription owners
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAA4eK1K9ghq8GxWMwN6=yKXTRJz7xbws+s2HiuyTV0oPokFTnQ@mail.gmail.com>
Date: Wed, 1 Dec 2021 11:21:35 -0800
Cc: Jeff Davis <pgsql@j-davis.com>,
 Andrew Dunstan <andrew@dunslane.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E93F649-C11A-40F0-BE34-6AB45507B807@enterprisedb.com>
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com>
 <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net>
 <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
 <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com>
 <aa28945f9f348307c8ac833a937b5fca732668b8.camel@j-davis.com>
 <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com>
 <b6f6ed921b6e219875801857204b14bbc8782e5e.camel@j-davis.com>
 <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com>
 <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
 <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com>
 <CAA4eK1LBjtqHH2h4TO7FHG=FJRfygfkeEb7AFj-dh6rqg3xqUA@mail.gmail.com>
 <CC5DAC9C-F767-4256-BFEF-32D5A566D254@enterprisedb.com>
 <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com>
 <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com>
 <CAA4eK1KnEptxtJTzo9LNb2VgRBYcBWxY+NSx2hJR8iUM8JXktw@mail.gmail.com>
 <18b267939a9d1ae27e9b3643d53395f4e29ea6ce.camel@j-davis.com>
 <CAA4eK1K1=DbXCNfA32urxZga6YxeiCvcTHvJu-+BtLCtVgqJ2w@mail.gmail.com>
 <785e8b8ab06f123cf754862557bd3171aeba4d65.camel@j-davis.com>
 <CAA4eK1JJsBzJsStA_LYrJu0WmOG+tWXcS9G4mY1G4CsQVBcaQw@mail.gmail.com>
 <c6681e45fb41e7397b3a7c353c607d2bfbcc9d87.camel@j-davis.com>
 <CAA4eK1K9ghq8GxWMwN6=yKXTRJz7xbws+s2HiuyTV0oPokFTnQ@mail.gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/4E93F649-C11A-40F0-BE34-6AB45507B807%40enterprisedb.com>
Precedence: bulk


> On Dec 1, 2021, at 5:36 AM, Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>=20
> On Wed, Dec 1, 2021 at 2:12 AM Jeff Davis <pgsql@j-davis.com> wrote:
>>=20
>> On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote:
>>> I think it would be better to do it before we allow subscription
>>> owners to be non-superusers.
>>=20
>> There are a couple other things to consider before allowing non-
>> superusers to create subscriptions anyway. For instance, a non-
>> superuser shouldn't be able to use a connection string that reads the
>> certificate file from the server unless they also have
>> pg_read_server_files privs.
>>=20
>=20
> Isn't allowing to create subscriptions via non-superusers and allowing
> to change the owner two different things? I am under the impression
> that the latter one is more towards allowing the workers to apply
> changes with a non-superuser role.

The short-term goal is to have logical replication workers respect the =
privileges of the role which owns the subscription.

The long-term work probably includes creating a predefined role with =
permission to create subscriptions, and the ability to transfer those =
subscriptions to roles who might be neither superuser nor members of any =
particular predefined role; the idea being that logical replication =
subscriptions can be established without any superuser involvement, and =
may thereafter run without any special privilege.

The more recent patches on this thread are not as ambitious as the =
earlier patch-sets.  We are no longer trying to support transferring =
subscriptions to non-superusers.

Right now, on HEAD, if a subscription owner has superuser revoked, the =
subscription can continue to operate as superuser in so far as its =
replication actions are concerned.  That seems like a pretty big =
security hole.

This patch mostly plugs that hole by adding permissions checks, so that =
a subscription owned by a role who has privileges revoked cannot (for =
the most part) continue to act under the old privileges.

There are two problematic edge cases that can occur after transfer of =
ownership.  Remember, the new owner is required to be superuser for the =
transfer of ownership to occur.

1) A subscription is transferred to a new owner, and the new owner then =
has privilege revoked.

2) A subscription is transferred to a new owner, and then the old owner =
has privileges increased.

In both cases, a currently running logical replication worker may finish =
a transaction in progress acting with the current privileges of the old =
owner.  The clearest solution is, as you suggest, to refuse transfer of =
ownership of subscriptions that are enabled.

Doing so will create a failure case for REASSIGN OWNED BY.  Will that be =
ok?

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company