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

From Jeff Davis
Subject Re: running logical replication as the subscription owner
Date
Msg-id bd16111e9b69d4090c2649b5633324d717e03c97.camel@j-davis.com
Whole thread Raw
In response to Re: running logical replication as the subscription owner  (Robert Haas <robertmhaas@gmail.com>)
List 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




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: running logical replication as the subscription owner
Next
From: Michael Paquier
Date:
Subject: Re: Raising the SCRAM iteration count