Re: Non-superuser subscription owners - Mailing list pgsql-hackers

On Mon, Jan 30, 2023 at 3:27 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> That was an aspirational example in which there's infinite daylight between the publisher and subscriber.  I, too,
doubtthat's ever going to be possible.  But I still think we should aspire to some extra daylight between the two.
PerhapsIANA doesn't publish to the whole world, but instead publishes only to subscribers who have a contract in place,
andhave agreed to monetary penalties should they abuse the publishing server.  Whatever.  There's going to be some
amountof daylight possible if we design for it, and none otherwise. 
>
> My real argument here isn't against your goal of having non-superusers who can create subscriptions.  That part seems
fineto me. 
>
> Given that my work last year made it possible for subscriptions to run as somebody other than the subscription
creator,it annoys me that you now want the subscription creator's privileges to be what the subscription runs as.  That
seemsto undo what I worked on.  In my mental model of a (superuser-creator, non-superuser-owner) pair, it seems you're
logicallyonly touching the lefthand side, so you should then have a (nonsuperuser-creator, nonsuperuser-owner) pair.
Butyou don't.  You go the apparently needless extra step of just squashing them together.  I just don't see why it
needsto be like that. 

I feel like you're accusing me of removing functionality that has
never existed. A subscription doesn't run as the subscription creator.
It runs as the subscription owner. If you or anyone else had added the
capability for it to run as someone other than the subscription owner,
I certainly wouldn't be trying to back that capability out as part of
this patch, and because there isn't, I'm not proposing to add that as
part of this patch. I don't see how that makes me guilty of squashing
anything together. The current state of affairs, where the run-as user
is taken from pg_subscription.subowner, the same field that is updated
by ALTER SUBSCRIPTION ... OWNER TO, is the result of your work, not
anything that I have done or am proposing to do.

I also *emphatically* disagree with the idea that this undoes what you
worked on. My patch would be *impossible* without your work. Prior to
your work, the run-as user was always, basically, the superuser, and
so the idea of allowing anyone other than a superuser to execute
CREATE SUBSCRIPTION would be flat-out nuts. Because of your work,
that's now a thing that we may be able to reasonably allow, if we can
work through the remaining issues. So I'm grateful to you, and also
sorry to hear that you're annoyed with me. But I still don't think
that the fact that the division you want doesn't exist is somehow my
fault.

I'm kind of curious why you *didn't* make this distinction at the time
that you were did the other work in this area. Maybe my memory is
playing tricks on me again, but I seem to recall talking about the
idea with you at the time, and I seem to recall thinking that it
sounded like an OK idea. I seem to vaguely recall us discussing
hazards like: well, what if replication causes code to get executed as
the subscription owner that that causes something bad to happen? But I
think the only way that happens is if they put triggers on the tables
that are being replicated, which is their choice, and they can avoid
installing problematic code there if they want. I think there might
have been some other scenarios, too, but I just can't remember. In any
case, I don't think the idea is completely without merit. I think it
could very well be something that we want to have for one reason or
another. But I don't currently understand exactly what those reasons
are, and I don't see any reason why one patch should both split owner
from run-as user and also allow the owner to be a non-superuser. That
seems like two different efforts to me.

--
Robert Haas
EDB: http://www.enterprisedb.com