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

From Amit Kapila
Subject Re: Non-superuser subscription owners
Date
Msg-id CAA4eK1+V5YaPn1R+_PDUCLMXx-tw7y2DrhV8hS0k8KzF1Kh-xg@mail.gmail.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 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Frontend error logging style
Next
From: vignesh C
Date:
Subject: Re: Printing backtrace of postgres processes