Re: Non-superuser subscription owners

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Non-superuser subscription owners
Date: 2021-11-17 15:44:27
Message-ID: 6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Nov 16, 2021, at 8:11 PM, Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-11-17 15:57:41 Re: Granting SET and ALTER SYSTE privileges for GUCs
Previous Message Xiaozhe Yao 2021-11-17 15:39:37 Re: Propose a new hook for mutating the query bounds