Horton
Menu

Re: running logical replication as the subscription owner

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Jelte Fennema <postgres@jeltef.nl>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, 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-27T17:14:15Z
Lists: pgsql-hackers 
On Sat, Mar 25, 2023 at 5:24 AM Jelte Fennema <postgres@jeltef.nl> wrote:
> For my purposes I always trust the publisher, what I don't trust is
> the table owners. But I can indeed imagine scenarios where that's the
> other way around, and indeed you can protect against that currently,
> but not with your new patch. That seems fairly easily solvable though.
>
> +   if (!member_can_set_role(context->save_userid, userid))
> +       ereport(ERROR,
> +               (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
> +                errmsg("role \"%s\" cannot SET ROLE to \"%s\"",
> +                       GetUserNameFromId(context->save_userid, false),
> +                       GetUserNameFromId(userid, false))));
>
> If we don't throw an error here, but instead simply return, then the
> current behaviour is preserved and people can manually configure
> permissions to protect against an untrusted publisher. This would
> still mean that the table owners can escalate privileges to the
> subscription owner, but if that subscription owner actually has fewer
> privileges than the table owner then you don't have that issue.

I don't get it. If we just return, that would result in skipping
changes rather than erroring out on changes, but it wouldn't preserve
the current behavior, because we'd still care about the table owner's
permissions rather than, as now, the subscription owner's permissions.

-- 
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.