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

Reply via email to