Re: running logical replication as the subscription owner - Mailing list pgsql-hackers

On Mon, 27 Mar 2023 at 22:47, Robert Haas <robertmhaas@gmail.com> wrote:
> Can a table owner defend themselves
> against a subscription owner who wants to usurp their privileges?

I have a hard time following the discussion. And I think it's because
there's lots of different possible privilege escalations to think
about. Below is the list of escalations I've gathered and how I think
they interact with the different patches:
1. Table owner escalating to a high-privileged subscription owner.
i.e. the subscription owner is superuser, or has SET ROLE privileges
for all owners of tables in the subscription.
2. Table owner escalating to a low-privileged subscription owner. e.g.
the subscription owner can only insert into the tables in its
subscription
    a. The subscription owner only has insert permissions for a tables
owned by a single other user
    b. The subscription owner has insert permissions for tables owned
by multiple other users (but still does not have SET ROLE, or possibly
even select/update/delete)
3. Publisher applying into tables that the subscriber side doesn't want it to
4. Subscription-owner escalating to table owner
    a. The subscription owner is highly privileged (allows SET ROLE to
table owner)
    b. The subscription owner is lowly privileged

Which can currently only be addressed by having 1
subscription/publication pair for every table owner. This has the big
issue that WAL needs to be decoded multiple times on the publisher.
This patch would make escalation 1 impossible without having to do
anything special when setting up the subscription. With Citus we only
run into this escalation issue with logical replication at the moment.
We want to replicate lots of different tables, possibly owned by
multiple users from one node to another. We trust the publisher and we
trust the subscription owner, but we don't trust the table owners at
all. This is why I'm very much in favor of a version of this patch.

2.a seems a non-issue, because in this case the table owner can easily
give itself the same permissions as the subscription owner (if it
didn't have them yet). So by "escalating" to the subscription owner
the table owner only gets fewer permissions. 2.b is actually
interesting from a security perspective, because by escalating to the
subscription owner, the table owner might be able to insert into
tables that it normally can't. Patch v1 would "solve" both these
issues by simply not supporting these scenarios. My patch v2 keeps the
existing behaviour, where both "escalations" are possible and who-ever
sets up the replication should create a dedicated subscriber for each
table owner to make sure that only 2.a ever occurs and 2.b does not.

3 is something I have not run into. But I can easily imagine a case
where a subscriber connects to a (somewhat) untrusted publisher for
the purpose of replicating changes from a single table, e.g. some
events table. But you don't want to allow replication into any other
tables, even if the publisher tells you to. Patch v1 would force you
to have SET ROLE privileges on the target events table its owner. So
if that owner owns other tables too, then effectively you'd allow the
publisher to write into those tables too. The current behaviour
(without any patch) supports protecting against this escalation, by
giving only INSERT permissions on a single table without the need for
SET ROLE. My v2 patch preserves that ability.

4.a again seems like an obvious non-issue to me because the
subscription owner can already "escalate" to table owner using SET
ROLE. 4.b seems like it's pretty much the same as 3, afaict all the
same arguments apply. And I honestly can't think of a real situation
where you would not trust the subscription owner (as opposed to the
publisher). If any of you have an example of such a situation I'd love
to understand this one better.

All in all, I think patch v2 is the right direction here, because it
covers all these escalations to some extent.