Re: running logical replication as the subscription owner

> On Mar 24, 2023, at 11:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I don't know how bad that sounds to you, and if it does sound bad, I
> don't immediately see how to mitigate it. As I said to Jeff, if you
> can replicate into a table that has a casually-written SECURITY
> INVOKER trigger on it, you can probably hack into the table owner's
> account.

I assume you mean this bit:

> > 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.


I don't find that terribly convincing.  First, there's no reason a subscription owner should be an ordinary user able
tovolitionally do anything.  The subscription owner should just be a role that the subscription runs under, as a means
ofsuperuser dropping privileges before applying changes.  So the only real problem would be that the changes coming
fromthe publisher might, upon application, hack the table owner.  But if that's the case, the table owner's
vulnerabilityon the subscription-database side is equal to their vulnerability on the publication-database side
(assumingequal schemas on both).  Flagging this vulnerability as being logical replication related seems a category
error. Instead, it's a schema vulnerability. 

> So I think that if we allow user A to replicate into user B's
> table with fewer privileges than A-can-set-role-to-B, we're building a
> privilege-escalation attack into the system. But if we do require
> A-can-set-role-to-B, then things change as described above.

I don't understand the direction this patch is going.  I'm emphatically not objecting to it, merely expressing my
confusionabout it. 

I had imagined the solution to the replication security problem was to stop running the replication as superuser, and
insteadas a trivial user.  Imagine that superuser creates roles "deadhead_bob" and "deadhead_alice" which cannot log
in,are not members of any groups nor have any other roles as members of themselves, and have no privileges beyond begin
ableto replicate into bob's and alice's tables, respectively.  The superuser sets up the subscriptions disabled,
transfersownership to deadhead_bob and deadhead_alice, and only then enables the subscriptions. 

Since deadhead_bob and deadhead_alice cannot log in, and nobody can set role to them, I don't see what the
vulnerabilityis.  Sure, maybe alice can attack deadhead_alice, or bob can attack deadhead_bob, but that's more of a
privilegedeescalation than a privilege escalation, so where's the risk?  That's not a rhetorical question.  Is there a
riskhere?  Or are we just concerned that most users will set up replication with superuser or some other high-privilege
user,and we're trying to protect them from the consequences of that choice? 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company