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: 
 <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
Date: Thu, 18 Nov 2021 07:33:53 -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: <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@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>
To: Amit Kapila <amit.kapila16@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/1BB0A553-3FE9-4A91-A975-6F9D8C157FBD%40enterprisedb.com>
Precedence: bulk


> On Nov 18, 2021, at 2:50 AM, Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>=20
>> I gave that a slight amount of thought during the design of this =
patch, but didn't think we could refuse to revoke superuser on such a =
basis, and didn't see what we should do with the subscription other than =
have it continue to be owned by the recently-non-superuser.  If you have =
a better idea, we can discuss it, but to some degree I think that is =
also orthogonal to the purpose of this patch.  The only sense in which =
this patch depends on that issue is that this patch proposes that =
non-superuser subscription owners are already an issue, and therefore =
that this patch isn't creating a new issue, but rather making more sane =
something that already can happen.
>>=20
>=20
> Don't we want to close this gap irrespective of the other part of the
> feature? I mean if we take out the part of your 0003 patch that checks
> whether the current user has permission to perform a particular
> operation on the target table then the gap related to the owner losing
> superuser privileges should be addressed.

I don't think there is a gap.  The patch does the right thing, causing =
the subscription whose owner has had superuser revoked to itself no =
longer function with superuser privileges.  Whether that causes the =
subscription to fail depends on whether the previously-superuser now =
non-superuser owner now lacks sufficient privileges on the target =
relation(s).  I think removing that part of the patch would be a =
regression.

Let's compare two scenarios.  In the first, we have a regular user =
"alice" who owns a subscription which replicates into table =
"accounting.receipts" for which she has been granted privileges by the =
table's owner.  What would you expect to happen after the table's owner =
revokes privileges from alice?  I would expect that the subscription can =
no longer function, and periodic attempts to replicate into that table =
result in permission denied errors in the logs.

In the second, we have a superuser "alice" who owns a subscription that =
replicates into table "accounting.receipts", and she only has sufficient =
privileges to modify "accounting.receipts" by virtue of being superuser. =
 I would expect that when she has superuser revoked, the subscription =
can likewise no longer function. =20

Now, maybe I'm wrong in both cases, and both should continue to =
function.  But I would find it really strange if the first situation =
behaved differently from the second.

I think intuitions about how subscriptions behave differ depending on =
the reason you expect the subscription to be owned by a particular user. =
 If the reason the user owns the subscription is that the user just =
happens to be the user who created it, but isn't in your mind associated =
with the subscription, then having the subscription continue to function =
regardless of what happens to the user, even the user being dropped, is =
probably consistent with your expectations.  In a sense, you think of =
the user who creates the subscription as having gifted it to the =
universe rather than continuing to own it.  Or perhaps you think of the =
creator of the subscription as a solicitor/lawyer/agent working on =
behalf of client, and once that legal transaction is completed, you =
don't expect the lawyer being disbarred should impact the subscription =
which exists for the benefit of the client.

If instead you think about the subscription owner as continuing to be =
closely associated with the subscription (as I do), then you expect =
changes in the owner's permissions to impact the subscription.

I think the "gifted to the universe"/"lawyer" mental model is not =
consistent with how the system is already designed to work.  You can't =
drop the subscription's owner without first running REASSIGN OWNED, or =
ALTER SUBSCRIPTION..OWNER TO, or simply dropping the subscription:

  DROP ROLE regress_subscription_user;
  ERROR:  role "regress_subscription_user" cannot be dropped because =
some objects depend on it
  DETAIL:  owner of subscription regress_testsub


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