public inbox for [email protected]  

help / color / mirror / Atom feed

From: Mark Dilger <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Robert Haas <[email protected]>
Subject: Re: Non-superuser subscription owners
Date: Fri, 19 Nov 2021 08:12:27 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1+V5YaPn1R+_PDUCLMXx-tw7y2DrhV8hS0k8KzF1Kh-xg@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAA4eK1+V5YaPn1R+_PDUCLMXx-tw7y2DrhV8hS0k8KzF1Kh-xg@mail.gmail.com>



> On Nov 19, 2021, at 2:23 AM, Amit Kapila <[email protected]> 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

view thread (68+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Non-superuser subscription owners
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox