Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Non-superuser subscription owners
Date
Msg-id C52A04DE-E9AB-4B8D-938B-BC91378C29DF@enterprisedb.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Non-superuser subscription owners
List pgsql-hackers

> On Nov 17, 2021, at 9:33 AM, Jeff Davis <pgsql@j-davis.com> wrote:
>
> Is GRANT a better fit here? That would allow more than one user to
> REFRESH, or ENABLE/DISABLE the same subscription. It wouldn't allow
> RENAME, but I don't see why we'd separate privileges for
> CREATE/DROP/RENAME anyway.

I don't think I answered this directly in my last reply.

GRANT *might* be part of some solution, but it is unclear to me how best to do it.  The various configuration
parameterson subscriptions entail different security concerns.  We might take a fine-grained approach and create a
predefinedrole for each, or we might take a course-grained approach and create a single pg_manage_subscriptions role
whichcan set any parameter on any subscription, or maybe just parameters on subscriptions that the role also owns, or
wemight do something else, like burn some privilege bits and define new privileges that can be granted per subscription
ratherthan globally.  (I think that last one is a non-starter, but just mention it as an example of another approach.) 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Propose a new hook for mutating the query bounds
Next
From: "Euler Taveira"
Date:
Subject: Re: Should we improve "PID XXXX is not a PostgreSQL server process" warning for pg_terminate_backend(<>)?