Horton
Menu

Re: Non-superuser subscription owners

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-01-20T01:51:22Z
Lists: pgsql-hackers 
Hi,

On 2023-01-19 17:16:20 -0800, Jeff Davis wrote:
> The predefined role is probably the biggest user-facing part of the
> change. Does it mean that members can create any number of any kind of
> subscription?

I don't think we need to support complicated restriction schemes around this
now. I'm sure such needs exist, but I think there's more places where a simple
"allowed/not allowed" suffices.

You'd presumably just grant such a permission to "pseudo superuser"
users. They can typically do a lot of bad things already, so I don't really
see the common need to prevent them from creating many subscriptions.


> If so it may be hard to tighten down later, because we don't know what
> existing setups might break.

Presumably the unlimited number of subs case would still exist as an option
later - so I don't see the problem?


> Perhaps we can just permit a superuser to "ALTER SUBSCRIPTION ... OWNER
> TO <non-super>", which makes it simpler to use while still leaving the
> responisbility with the superuser to get it right. Maybe we even block
> the user from altering their own subscription (would be weird but not
> much weirder than what we have now)? I don't know if that solves the
> problem you're trying to solve, but it seems lower-risk.

That seems to not really get us very far. It's hard to use for users, and hard
to make secure for the hosted PG providers.

Greetings,

Andres Freund

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.