> On Nov 19, 2021, at 2:23 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> 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.
I feel disquieted about the "runas" idea. I can't really say why yet. Maybe
it is ok, but it feels like a larger design decision than just an
implementation detail about how subscriptions work. We should consider if we
won't soon be doing the same thing for other parts of the system. If so, we
should choose a solution that makes sense when applied more broadly.
Security definer functions could benefit from splitting the owner from the
runas role.
Event triggers might benefit from having a runas role. Currently, event
triggers are always owned by superusers, but we've discussed allowing
non-superuser owners. That proposal still has outstanding issues to be
resolved, so I can't be sure if runas would be helpful, but it might.
Table triggers might benefit from having a runas role. I don't have a proposal
here, just an intuition that we should think about this before designing how
"runas" works.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
