Re: running logical replication as the subscription owner

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: running logical replication as the subscription owner
Date: 2023-03-25 00:26:11
Message-ID: bd16111e9b69d4090c2649b5633324d717e03c97.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2023-03-24 at 14:35 -0400, Robert Haas wrote:
> That
> actually wouldn't work today, and with the patch it would start
> working, so basically the effect of the patch on the problem that you
> mention would be to remove the ability to filter by specific table
> and
> add the ability to filter by owning role.

That's certainly a loss. It makes a lot of sense to want to limit a
subscription to only write to certain tables.

If you want to filter by role, you can do that today by granting the
role, or some role that has the necessary privileges.

It takes me a while to re-learn the problems of poorly-written trigger
functions, malicious trigger functions, search paths, etc., each time I
start working in this area again. Can you include an example of such a
trigger function that we're worried about? Can the subscription owner
change the search path in the subscription process, and if so, why?

The doc here:

https://www.postgresql.org/docs/devel/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY

mentions search_path, but other hazards don't really seem applicable.
(Is the trigger creating new roles?)

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-03-25 00:56:29 Re: Raising the SCRAM iteration count
Previous Message Jeff Davis 2023-03-25 00:02:18 Re: running logical replication as the subscription owner