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 →
  1. Fix possible crash in tablesync worker.

  2. Display 'password_required' option for \dRs+ command.

  3. Restart the apply worker if the 'password_required' option is changed.

  4. Fix possible logical replication crash.

  5. Add new predefined role pg_create_subscription.

  6. Expand AclMode to 64 bits

  7. More cleanup of a2ab9c06ea.

  8. Respect permissions within logical replication.

  9. Improve table locking behavior in the face of current DDL.