On Mon, Jan 30, 2023 at 1:46 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > I have a grim view of the requirement that publishers and subscribers trust > each other. Even when they do trust each other, they can firewall attacks by > acting as if they do not.
I think it's OK if the CREATE PUBLICATION user doesn't particularly trust the CREATE SUBSCRIPTION user, because the publication is just a grouping of tables to which somebody can pay attention or not. The CREATE PUBLICATION user isn't compromised either way. But, at least as things stand, I don't see how the CREATE SUBSCRIPTION user get away with not trusting the CREATE PUBLICATION user. CREATE SUBSCRIPTION provides no tools at all for filtering the data that the subscriber chooses to send. Now that can be changed, I suppose, and a run-as user would be one way to make progress in that direction. But I'm not sure how viable that is, because... > > In what > > circumstances would be it be reasonable to give responsibility for > > those objects to different and especially mutually untrusting users? > > When public repositories of data, such as the IANA whois database, publish > their data via postgres publications. ... for that to work, IANA would need to set up the database so that untrusted parties can create logical replication slots on their PostgreSQL server. And I think that granting REPLICATION privilege on your database to random people on the Internet is not really viable, nor intended to be viable. As the CREATE ROLE documentation says, "A role having the REPLICATION attribute is a very highly privileged role." Concretely, this kind of setup would have the problem that you could kill the IANA database by just creating a replication slot and then not using it (or replicating from it only very very slowly). Eventually, the replication slot would either hold back xmin enough that you got a lot of bloat, or cause enough WAL to be retained that you ran out of disk space. Maybe you could protect yourself against that kind of problem by cutting off users who get too far behind, but that also cuts off people who just have an outage for longer than your cutoff. Also, anyone who can connection to a replication slot can also connect to any other replication slot, and drop any replication slot. So if IANA did grant REPLICATION privilege to random people on the Internet, one of them could jump into the system and screw things up for all the others. This kind of setup just doesn't seem viable to me. -- Robert Haas EDB: http://www.enterprisedb.com
