Re: Non-superuser subscription owners
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>,
Andrew Dunstan <andrew@dunslane.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2021-12-07T14:55:51Z
Lists: pgsql-hackers
> On Dec 7, 2021, at 2:29 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > Okay, let me try to explain again. Following is the text from docs > [1]: " (a) To create a subscription, the user must be a superuser. (b) > The subscription apply process will run in the local database with the > privileges of a superuser. (c) Privileges are only checked once at the > start of a replication connection. They are not re-checked as each > change record is read from the publisher, nor are they re-checked for > each change when applied. > > My understanding is that we want to improve what is written as (c) > which I think is the same as what you mentioned later as "Fix the > current bug wherein subscription changes are applied with superuser > force after the subscription owner has superuser privileges revoked.". > Am I correct till here? If so, I think what I am suggesting should fix > this with the assumption that we still want to follow (b) at least for > the first patch. Ok, that's a point of disagreement. I was trying to fix both (b) and (c) in the first patch. > One possibility is that our understanding of the > first problem is the same but you want to allow apply worker running > even when superuser privileges are revoked provided the user with > which it is running has appropriate privileges on the objects being > accessed by apply worker. Correct, that's what I'm trying to make safe. > We will talk about other points of the roadmap you mentioned once our > understanding for the first one matches. I am happy to have an off-list phone call with you, if you like. — 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 →
-
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