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>
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-30 05:19:02
Message-ID: 4177972fc680f48b6930273dfaa8922b7a49fac7.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2023-03-29 at 16:00 -0400, Robert Haas wrote:
> Here's a new patch set to show how this would work. 0001 is as
> before.

The following special case ("unless they can SET ROLE..."):

/*
* Try to prevent the user to which we're switching from assuming the
* privileges of the current user, unless they can SET ROLE to that
* user anyway.
*/

which turns SwitchToUntrustedUser() into a no-op, is conceptually
redundant with patch 0002. The only difference is that the former (in
0001) is implicit and the latter (in 0002) is declared.

I say just take the special case out of 0001. If the trigger doesn't
work as a SECURITY_RESTRICTED_OPERATION, and is also ENABLED ALWAYS,
then the user can just use the new option in 0002 to get the old
behavior. I don't see a reason to implicitly give them the old
behavior, as 0001 does.

> 0002 adds a run_as_owner option to subscriptions. This doesn't make
> the updated regression tests fail, because they don't use it. If you
> revert the changes to 027_nosuperuser.pl then you get failures (as
> one
> would hope) and if you then add WITH (run_as_owner = true) to the
> CREATE SUBSCRIPTION command in 027_nosuperuser.pl then it passes
> again. I need to spend some more time thinking about what the tests
> actually ought to look like if we go this route -- I haven't looked
> through what Jelte proposed yet -- and also the documentation would
> need a bunch of updating.

"run_as_owner" is ambiguous -- subscription owner or table owner?

I would prefer something like "trust_table_owners". That would
communicate that the user shouldn't choose it unless they know what
they're doing.

> And either way, at least PostgreSQL
> hacker who has taken the time to write about this topic is going to
> think we've made a poor call, or at best a dubious one, and either
> way,

If you are worried that *I* think 0002 would be a poor call, then no, I
don't. Initially I didn't like the idea of supporting two behaviors
(and who would?), but we probably can't avoid it at least for right
now.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-03-30 05:28:13 RE: Time delayed LR (WAS Re: logical replication restrictions)
Previous Message Justin Pryzby 2023-03-30 05:07:58 Re: ALTER TABLE SET ACCESS METHOD on partitioned tables