Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Date
Msg-id d00be2e935ae191a12bea494c7151a1b19343bf7.camel@j-davis.com
Whole thread Raw
In response to Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)  (Noah Misch <noah@leadboat.com>)
Responses Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Thu, 2021-05-27 at 23:06 -0700, Noah Misch wrote:
> pg_logical_replication would not be safe to delegate that way:
> 
https://postgr.es/m/flat/CACqFVBbx6PDq%2B%3DvHM0n78kHzn8tvOM-kGO_2q_q0zNAMT%2BTzdA%40mail.gmail.com

What do you mean "that way"? Do you mean it's not safe to delegate
subscription creation to non-superusers at all?

From the thread above, I don't see anything so dangerous that it can't
be delegated:

  * persistent background workers on subscriber
    - still seems reasonable to delegate to a privileged user
  * arbitrary code execution by the apply worker on subscriber
    - apply worker runs as subscription owner, so doesn't seem
      like a problem?
  * connection info may be visible to non-superusers
    - seems either solvable or not necessarily a problem

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Split xlog.c
Next
From: Andres Freund
Date:
Subject: Re: Interrupts vs signals