On Mon, Jan 30, 2023 at 3:27 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > That was an aspirational example in which there's infinite daylight between > the publisher and subscriber. I, too, doubt that's ever going to be > possible. But I still think we should aspire to some extra daylight between > the two. Perhaps IANA doesn't publish to the whole world, but instead > publishes only to subscribers who have a contract in place, and have agreed > to monetary penalties should they abuse the publishing server. Whatever. > There's going to be some amount of 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 fine to 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 seems to undo what I worked on. In my mental model of a > (superuser-creator, non-superuser-owner) pair, it seems you're logically only > touching the lefthand side, so you should then have a (nonsuperuser-creator, > nonsuperuser-owner) pair. But you don't. You go the apparently needless > extra step of just squashing them together. I just don't see why it needs to > 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
