On Thu, 2023-03-30 at 16:08 -0400, Robert Haas wrote:
> But the run_as_owner option applies to the entire subscription.
> If A activates that option, then B's hypothetical triggers that run
> afoul of the SECURITY_RESTRICTED_OPERATION restrictions start working
> again (woohoo!) but they're now vulnerable to attacks from C. With
> the
> patch as coded, A doesn't need to use run_as_owner, everything still
> just works for B, and A is still protected against C.
That's moving the goalposts a little, though:
"Some concern was expressed ... might break things that are currently
working..."
https://www.postgresql.org/message-id/CA+TgmoaE35kKS3-zSvGiZszXP9Tb9rNfYzT=+fO8Ehk5EDKrag@mail.gmail.com
If the original use case was "don't break stuff", I think patch 0002
solves that, and we don't need this special case in 0001. Would you
agree with that statement?
Hypothetically, if 0001 (without the special case) along with 0002 were
already in 16, and then there was some hypothetical 0003 that
introduced the special case to solve the problem described above with
the bidirectional trust relationship, I'm not sure I'd be sold on 0003.
First, the problem seems fairly minor to me, at least in comparison to
the main problem you are solving in this thread. Second, it seems like
you could work around it by having two subscriptions. Third, it's a bit
unintuitive at least to me: if you introduce a new user Z that can SET
ROLE to any of A, B, or C, and then Z reassigns the subscription to
themselves, then B's trigger will break because B can't SET ROLE to Z.
Others seem to like it, so don't take that as a hard objection.
>
> But I imagine CREATE SUBSCRIPTION being used either by
> superusers or by people who already have those role grants anyway,
> because I imagine replication as something that a highly privileged
> user configures on behalf of everyone who uses the system. And in
> that
> case those role grants aren't something new that you do specifically
> for logical replication - they're already there because you need them
> to administer stuff. Or you're the superuser and don't need them
> anyway.
Did the discussion drift back towards the SET ROLE in the other
direction? I thought we had settled that in v16 we would require that
the subscription owner can SET ROLE to the table owner (as in your
current 0001), but that we could revisit it later.
Regards,
Jeff Davis
