Re: Non-superuser subscription owners
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Andres Freund <andres@anarazel.de>,
Mark Dilger <mark.dilger@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-03-24T13:24:54Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix possible crash in tablesync worker.
- b5c517379a40 16.0 landed
-
Display 'password_required' option for \dRs+ command.
- 19e65dff38bd 16.0 landed
-
Restart the apply worker if the 'password_required' option is changed.
- c1cc4e688b60 16.0 landed
-
Fix possible logical replication crash.
- e7e7da2f8d57 16.0 landed
-
Add new predefined role pg_create_subscription.
- c3afe8cf5a1e 16.0 landed
-
Expand AclMode to 64 bits
- 7b378237aa80 16.0 cited
-
More cleanup of a2ab9c06ea.
- 96a6f11c0625 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 landed
-
Improve table locking behavior in the face of current DDL.
- 2ad36c4e44c8 9.2.0 cited