Re: Non-superuser subscription owners

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: Non-superuser subscription owners
Дата
Msg-id C52A04DE-E9AB-4B8D-938B-BC91378C29DF@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Propose a new hook for mutating the query bounds
Следующее
От: "Euler Taveira"
Дата:
Сообщение: Re: Should we improve "PID XXXX is not a PostgreSQL server process" warning for pg_terminate_backend(<>)?