Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync

[Nathaniel Smith]

On Fri, Mar 02, 2007 at 03:37:50PM +0100, Ulf Ochsenfahrt wrote:
> Consider the following case:
> Branch    A | B
> Revision  x |
> 
> You have no access to A, and both read and write access to B.
> 
> Right now, you can write a certificate stating that revision x is part 
> of branch B. If you have read access to B, then you can read revision x 
> (and all its ancestors), even if it was originally in A to which _you do 
> not have read access_.
> Branch    A | B
> Revision  x | x

Right.  This sort of problem is the real reason why we don't have
fine-grained write control.  Just blocking branch certs that don't
match the pattern we expect is not at all sufficient.

> One solution is to block branch certificates. However, you can still get 
> the contents of revision x. You do this by creating a revision x' that 
> is a child of x, and put that in branch B. Then netsync will 
> automatically tell you the contents of x in A, to which _you do not have 
> read access_.
> Branch    A | B
> Revision  x |
>            \|
>             \
>             |\
>             | x'
> 
> So, the correct solution is to block both branch certificates and 
> revisions that have a parent in a branch to which you do not have read 
> access.
> 
> However, what happens if you got revision x from elsewhere, and you want 
> to create x' in B?
> 
> You can do this by proving to netsync that you know the contents of x. 
> In fact, you should also have to prove that you know the entire history 
> of x, because you just effectively published it on branch B.
> 
> There's the catch. Giving a revision a branch certificate in another 
> branch gives allows anyone with read access to that branch access to the 
> entire history of that revision.

Note that the way netsync is currently set up, every new revision is
first sent without any branch info, and then the branch info is sent
for that revision.  So effectively every branch cert you send looks
like you are trying to steal permission to look at a pre-existing
revision.

I'm not sure how the solve this -- I suppose each connection would
have to track in memory the complete set of revisions that read access
was granted to, and also all revisions that have been sent down this
connection?

I don't know if there are other similar security problems -- netsync
is complicated.  But I guess if you want this feature, you should
make sure you know that you have thought of everything :-).  Everyone
would be perfectly happy to see more capable access controls for
netsync, it's just not clear how to actually _get_ such a thing
without redesigning whole chunks.

BTW, the sourceforge example is a red herring for other reasons -- all
our code assumes that network operations are generally database-wide,
so their efficiency tends to be O(whole database), not O(subsets of
database involved in this particular sync).  This is not particularly
fixable -- trying to sieve out 100 megabytes of relevant data from a
multi-gigabyte (or multi-terabyte, for sourceforge) database is never
going to be fast; you need some kind of lower level data partitioning.
So in any kind of large hosting situation, you would certainly be
using some sort of vhost support and multiple databases anyway.  Also,
sourceforge probably wants a security model that is simple to analyze,
which netsync-based security is unlikely to be...

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender