Re: running logical replication as the subscription owner

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2023-04-03T14:26:30Z
Lists: pgsql-hackers
On Fri, Mar 31, 2023 at 6:46 PM Jeff Davis <pgsql@j-davis.com> wrote:
> I guess the "more convenient" is where I'm confused, because the "grant
> subscription_owner to table owner with set role true" is not likely to
> be conveniently already present; it would need to be issued manually to
> take advantage of this special case.

You and I disagree about the likelihood of that, but I could well be wrong.

> Do you have any concern about the weirdness where assigning the
> subscription to a higher-privilege user Z would cause B's trigger to
> fail?

Not very much. I think the biggest risk is user confusion, but I don't
think that's a huge risk because I don't think this scenario will come
up very often. Also, it's kind of hard to imagine that there's a
security model here which never does anything potentially surprising.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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.