Re: [Monotone-devel] The new definition of get_netsync_write_permitted

[Nathaniel Smith]

On Wed, Jul 06, 2005 at 09:55:38PM +0200, Richard Levitte - VMS Whacker wrote:
> I've a problem with the new definition of get_netsync_write_permitted
> (where it only takes an identity string).
> 
> I've a server where I serve a number of projects, among others a
> mirror of the monotone database.  With the new definition, anyone I
> allow write access to my server thinking I'm granting him/her write
> access to one specific project, automagically has write access to
> *all* the projects I serve (including, for instance, monotone) and can
> therefore generate rogue commits.

This is true about the new definition.  It was also, however, true
about the old definition.  Once write permission was granted, monotone
did no further checking of the data that was sent.  The way the
netsync protocol is currently done, this is tricky to get around...

Tim Brownawell tried tightening this up when he got rid of
collections, but his approach turned out not to work very well:
  
http://www.loglibrary.com/show_page/view/106?Multiplier=3600&Interval=6&StartTime=1120382020

There are some things that make it hard to get this right:
  -- we don't actually know ahead of time what branches a client will
     try to write to.  they may want to push a branch which we have
     never encountered before.
  -- even if someone only has write access to a particular branch,
     they can still put all sorts of random junk in your db; they can
     commit a revision whose parent is on another branch, or write
     large files that are not part of any revision.
  -- the rule is that if you have access to revision A, then you also
     have access to all ancestors of A.  And if you have write access,
     you can always just create revision A; or turn any existing
     revision into revision A but pushing a branch cert.  This means
     that if you give someone write access at all, then they can get
     themselves global read access.

Moral: making netsync enforce interesting policies is... really a bit
tricky.  Definitely something we need to work on, but for now, it
seemed simplest to just warn people that if you give someone write
permission, that's giving them pretty broad access -- at least the
current thing works correctly, is no worse than what we had before,
and let us get the release out.

It is worth keeping in mind, though, that monotone was originally
designed to use completely untrustworthy channels of communication;
even if someone gets up to shenanigans, abuses their write access, or
whatever, all they can do is insert new cryptographic information into
the network -- they can't frame anyone else without stealing a key,
the worst they can do is make their games anonymous by making up a new
key just for their games.  It should always be pretty much obvious
what's going on.

> Oh sure, I can have a private rc with a get_revision_cert_trust that
> makes sure I don't see those rogue commits, but what about anyone else
> who pulls from my server?  Is there any way to prevent rogue commits
> from spreading?

There is some philosophical difference here, perhaps; monotone tries
to avoid assuming that just because you consider a commit to be
'rogue', everyone else will as well.  Of course, we don't really have
any mechanism in place yet to make this more reasonable;
get_revision_cert_trust is handy, but obviously not a sufficient
solution in the long run.  It just happens to be all that we have
right now.

Solving this problem may make what to do with netsync more clear,
though.

-- Nathaniel

-- 
I have my moments.  And soon, I will have yours, too.

This email may be read aloud.