public inbox for [email protected]
help / color / mirror / Atom feedFrom: Mark Dilger <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Robert Haas <[email protected]>
Subject: Re: Non-superuser subscription owners
Date: Wed, 1 Dec 2021 11:21:35 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1K9ghq8GxWMwN6=yKXTRJz7xbws+s2HiuyTV0oPokFTnQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
<[email protected]>
<CAA4eK1LBjtqHH2h4TO7FHG=FJRfygfkeEb7AFj-dh6rqg3xqUA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA4eK1KnEptxtJTzo9LNb2VgRBYcBWxY+NSx2hJR8iUM8JXktw@mail.gmail.com>
<[email protected]>
<CAA4eK1K1=DbXCNfA32urxZga6YxeiCvcTHvJu-+BtLCtVgqJ2w@mail.gmail.com>
<[email protected]>
<CAA4eK1JJsBzJsStA_LYrJu0WmOG+tWXcS9G4mY1G4CsQVBcaQw@mail.gmail.com>
<[email protected]>
<CAA4eK1K9ghq8GxWMwN6=yKXTRJz7xbws+s2HiuyTV0oPokFTnQ@mail.gmail.com>
> On Dec 1, 2021, at 5:36 AM, Amit Kapila <[email protected]> wrote:
>
> On Wed, Dec 1, 2021 at 2:12 AM Jeff Davis <[email protected]> wrote:
>>
>> 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.
>>
>> 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.
>>
>
> 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?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
view thread (68+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Non-superuser subscription owners
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox