> > There are certainly a bunch of interesting challenges around providing > identities that are meaningful across multiple servers in different > domains, and I think that’s worth digging into, but I wanted to avoid > anyone thinking that replication could trivially defeat the per-doc _access > controls that Jan has been working on here. Cheers, > > I think it depends on what you mean by "defeat". I haven't heard enough that suggests replication can't trivially defeat access controls yet.... That's exactly the question I'm asking.
Let's look at two specific cases: ---------------- So in one case, it's a "pull only" replica; say you are pulling from my server to yours. Once you read your available docs into your DB, you can grant yourself write privileges to every document there. My original database is obviously unchanged, but in a more p2p environment where the idea is that the data is "daisy chaining" between replicas in a "mesh" instead of a "star" topology; the access controls on documents in the mesh is completely untrustworthy if those kinds of rewrites can happen. The other case is a bi-directional replication scenario because we want both our servers to have "some" write access to "some" documents in a database that we share, such that we wish to replicate the full set of documents between each other but maintain access controls. This case seems to completely break down because you can modify any document you have read access to and then I could easily replicate those changes back from you. ......... In the scenarios I'm envisioning, once a document gets onto a machine, the administrator of that machine can completely rewrite the access controls to any document (and by extension rewrite the document itself); if those changes are able to replicate out to other databases, and especially back up to the original source, that's what I see poses a problem. I suppose one fix idea is that when replicating, outbound uses read access controls and inbound enforces write access controls; but this would have to be at the level of tracking what entity made the modifications and not the entity doing the replication. I'm looking at scenarios where there is more than one user accessing the replica because it's a multimaster distributed infoset scenario. Perhaps you are thinking that the model is more "hub and spoke" where the replica is only for a singular user?