Re: Non-superuser subscription owners

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-11-17T15:44:27Z
Lists: pgsql-hackers

> On Nov 16, 2021, at 8:11 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> 
> On Wed, 2021-11-03 at 12:50 -0700, Mark Dilger wrote:
>> The first two patches are virtually unchanged.  The third updates the
>> behavior of the apply workers, and updates the documentation to
>> match.
> 
> v2-0001 corrects some surprises, but may create others. Why is renaming
> allowed, but not changing the options? What if we add new options, and
> some of them seem benign for a non-superuser to change?

The patch cannot anticipate which logical replication options may be added to the project in some later commit.  We can let that commit adjust the behavior to allow the option if we agree it is sensible for non-superusers to do so.

> The commit message part of the patch says that it's to prevent non-
> superusers from being able to (effectively) create subscriptions, but
> don't we want privileged non-superusers to be able to create
> subscriptions?

Perhaps, but I don't think merely owning a subscription should entitle a role to create new subscriptions.  Administrators may quite intentionally create low-power users, ones without access to anything but a single table, or a single schema, as a means of restricting the damage that a subscription might do (or more precisely, what the publisher might do via the subscription.)  It would be surprising if that low-power user was then able to recreate the subscription into something different.

We should probably come back to this topic in a different patch, perhaps a patch that introduces a new pg_manage_subscriptions role or such.

—
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.