Re: running logical replication as the subscription owner

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2023-03-24T16:58:57Z
Lists: pgsql-hackers

> On Mar 24, 2023, at 7:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> More generally, Stephen Frost has elsewhere argued that we should want
> the subscription owner to be a very low-privilege user, so that if
> their privileges get stolen, it's no big deal. I disagree with that. I
> think it's always a problem if one user can get unauthorized access to
> another user's account, regardless of exactly what those accounts can
> do. I think our goal should be to make it safe for the subscription
> owner to be a very high-privilege user, because you're going to need
> to be a very high-privilege user to set up replication. And if you do
> have that level of privilege, it's more convenient and simpler if you
> can just own the subscription yourself, rather than having to make a
> dummy account to own it. To put that another way, I think that what
> people are going to want to do in a lot of cases is have the superuser
> own the subscription, so I think we need to make that case safe,
> whatever it takes.

I also think the subscription owner should be a low-privileged user, owing to the risk of the publisher injecting malicious content into the publication.  I think you are focused on all the bad actors on the subscription-side database and what they can do to each other.  That's also valid, but I get the impression that you're losing sight of the risk posed by malicious publishers.  Or maybe you aren't, and can explain?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Honor run_as_owner option in tablesync worker.

  2. Document new pg_subscription columns.

  3. Add a run_as_owner option to subscriptions.

  4. Perform logical replication actions as the table owner.

  5. Add new predefined role pg_create_subscription.

  6. Respect permissions within logical replication.

  7. Empty search_path in logical replication apply worker and walsender.

  8. Empty search_path in Autovacuum and non-psql/pgbench clients.