Re: running logical replication as the subscription owner

On Fri, 2023-03-24 at 10:00 -0400, Robert Haas wrote:
> On Fri, Mar 24, 2023 at 3:59 AM Jeff Davis <pgsql@j-davis.com> wrote:
> > That's a little confusing, why not just always use the
> > SECURITY_RESTRICTED_OPERATION? Is there a use case I'm missing?
> 
> Some concern was expressed -- not sure exactly where the email is
> exactly, and it might've been on pgsql-security -- that doing that
> categorically might break things that are currently working. The
> people who were concerned included Andres and I forget who else. My
> gut reaction was the same as yours, just do it always and don't worry
> about it. But if people think that users are likely to run afoul of
> the SECURITY_RESTRICTED_OPERATION restrictions in practice, then this
> is better, and the implementation complexity isn't high. We could
> even
> think of extending this kind of logic to other places where
> SECURITY_RESTRICTED_OPERATION is enforced, if desired.

Without a reasonable example, we should probably be on some kind of
path to disallowing crazy stuff in triggers that poses only risks and
no benefits. Not the job of this patch, but perhaps it can be seen as a
step in that direction?

> 
> I am not thrilled with this either, but if you can arrange to run
> code
> as a certain user without the ability to SET ROLE to that user then
> there is, by definition, a potential privilege escalation.

I don't think that's "by definition".

The code is being executed with the privileges of the person who wrote
it. I don't see anything inherently insecure about that. There could be
incidental or practical risks, but it's a pretty reasonable thing to do
at a high level.

>  I don't
> think we can just dismiss that as a non-issue. If the ability of one
> user to potentially become some other user weren't a problem, we
> wouldn't need any patch at all. Imagine for example that the table
> owner has a trigger which doesn't sanitize search_path. The
> subscription owner can potentially leverage that to get the table
> owner's privileges.

Can you explain? Couldn't we control the subscription process's search
path?

> In cases where the subscription owner isn't the
> superuser, I think the next most likely possibility is that the
> subscription owner is some kind of almost-super-user

The benefit of delegating to a non-superuser is to contain the risk if
that account is compromised. Allowing SET ROLE on tons of accounts
diminishes that benefit, a lot.

Regards,
	Jeff Davis