Re: Non-superuser subscription owners

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Non-superuser subscription owners
Дата
Msg-id CAA4eK1+V5YaPn1R+_PDUCLMXx-tw7y2DrhV8hS0k8KzF1Kh-xg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Non-superuser subscription owners  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Non-superuser subscription owners  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers
On Fri, Nov 19, 2021 at 12:00 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote:
> >  You must choose a single role you want the subscription to run
> > under.
>
> I think that was the source of a lot of my confusion:
>
> Your patches are creating the notion of a "run as" user by assigning
> ownership-that-isn't-really-ownership. I got distracted wondering why
> you would really care if some user could enable/disable/refresh/rename
> a subscription, but the main point was to change who the subscription
> runs as.
>
> That's a more general idea: I could see how "run as" could apply to
> subscriptions as well as functions (right now it can only run as the
> owner or the invoker, not an arbitrary role). And I better understand
> your analogy to security definer now.
>

I was thinking why not separate the ownership and "run as" privileges
for the subscriptions? We can introduce a new syntax in addition to
the current syntax for "Owner" for this as:

Create Subscription sub RUNAS <role_name> ...;
Alter Subscription sub RUNAS <role_name>

Now, RUNAS role will be used to apply changes and perform the initial
table sync. The owner will be tied to changing some of the other
properties (enabling, disabling, etc.) of the subscription. Now, we
still need a superuser to create subscription and change properties
like CONNECTION for a subscription but we can solve that by having
roles specific to it as being indicated by Mark in some of his
previous emails.

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Frontend error logging style
Следующее
От: vignesh C
Дата:
Сообщение: Re: Printing backtrace of postgres processes