Re: running logical replication as the subscription owner
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>,
Noah Misch <noah@leadboat.com>
Date: 2023-03-24T16:58:57Z
Lists: pgsql-hackers
> On Mar 24, 2023, at 7:00 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > More generally, Stephen Frost has elsewhere argued that we should want > the subscription owner to be a very low-privilege user, so that if > their privileges get stolen, it's no big deal. I disagree with that. I > think it's always a problem if one user can get unauthorized access to > another user's account, regardless of exactly what those accounts can > do. I think our goal should be to make it safe for the subscription > owner to be a very high-privilege user, because you're going to need > to be a very high-privilege user to set up replication. And if you do > have that level of privilege, it's more convenient and simpler if you > can just own the subscription yourself, rather than having to make a > dummy account to own it. To put that another way, I think that what > people are going to want to do in a lot of cases is have the superuser > own the subscription, so I think we need to make that case safe, > whatever it takes. I also think the subscription owner should be a low-privileged user, owing to the risk of the publisher injecting malicious content into the publication. I think you are focused on all the bad actors on the subscription-side database and what they can do to each other. That's also valid, but I get the impression that you're losing sight of the risk posed by malicious publishers. Or maybe you aren't, and can explain? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Honor run_as_owner option in tablesync worker.
- a83edeaf684a 16.0 landed
-
Document new pg_subscription columns.
- bc25d6c54a00 16.0 landed
-
Add a run_as_owner option to subscriptions.
- 482675987bcd 16.0 landed
-
Perform logical replication actions as the table owner.
- 1e10d49b65d6 16.0 landed
-
Add new predefined role pg_create_subscription.
- c3afe8cf5a1e 16.0 cited
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 cited
-
Empty search_path in logical replication apply worker and walsender.
- 11da97024abb 14.0 cited
-
Empty search_path in Autovacuum and non-psql/pgbench clients.
- 582edc369cdb 11.0 cited