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

From Robert Haas
Subject Re: Non-superuser subscription owners
Date
Msg-id CA+TgmobOcvMnaAp7aAC8yYGjoBQzKeC6wx+MFXRBU4bLGS4XXA@mail.gmail.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Non-superuser subscription owners  (Robert Haas <robertmhaas@gmail.com>)
Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Fri, Mar 24, 2023 at 3:17 AM Jeff Davis <pgsql@j-davis.com> wrote:
> The current patch (non-superuser-subscriptions) is the most user-facing
> aspect, and it seems wrong to commit it before we have the security
> model in a reasonable place. As you pointed out[1], it's not in a
> reasonable place now, so encouraging more use seems like a bad idea.

I certainly agree that the security model isn't in a reasonable place
right now. However, I feel that:

(1) adding an extra predefined role doesn't really help, because it
doesn't actually do anything in and of itself, it only prepares for
future work, and

(2) even adding the connection string security stuff that you're
proposing doesn't really help, because (2a) connection string security
is almost completely separate from the internal security
considerations addressed in the message to which you linked, and (2b)
in my opinion, there will be a lot of people who won't use that
connection string security stuff even if we had it, possibly even a
large majority of people won't use it, because it responds to a
specific use case which I think a lot of people don't have, and

(3) I don't agree either that this patch would encourage more use of
logical replication or that it would be bad if it did. I mean, there
could be someone who knows about this patch and will hesitate to
deploy logical replication if it doesn't get committed, or maybe
slightly more likely, won't be able to do so if this patch doesn't get
committed because they're running in a cloud environment. But probably
not. Cloud providers are already hacking around this problem,
Microsoft included. As a community, we're better off having a standard
solution in core than having every vendor hack it their own way. And
outside of a cloud environment, there's not really any reason for the
lack of this patch to make a potential user hesitate. Also, features
getting used is a thing that I think we should all want. If logical
replication is in such a bad state that we think people should be
using it, we should rip it out until the issues are fixed. I don't
think anyone would seriously propose that such a course of action is
advisable. So the alternative is to make it better.

To reiterate what I think the most important point here is, both Azure
and AWS already let you do this. EDB's own cloud offering is also
going to let you do this, whether this change goes in or not. But if
this patch gets committed, then eventually all of those vendors and
whatever others are out there will let you do this in the same way,
i.e. pg_create_subscription, instead of every vendor having their own
patch to the code that does what this patch does through some method
that is specific to that cloud vendor. That sort of fragmentation of
the ecosystem is not good for anyone, AFAICS.

> The other patch you posted seems like it makes a lot of progress in
> that direction, and I think that should go in first. That was one of
> the items I suggested previously[2], so thank you for working on that.

Perhaps you could review that work?

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



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Request for comment on setting binary format output per session
Next
From: "Imseih (AWS), Sami"
Date:
Subject: Re: [BUG] pg_stat_statements and extended query protocol