Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension & Abstraction Layer

[Ralf S. Engelschall]

On Sun, Sep 23, 2007, Ralf S. Engelschall wrote:

> On Sun, Sep 23, 2007, Nathaniel Smith wrote:
> > [...]
> > > My partner Thomas Lotterer and I came up with the idea to solve the
> > > problem at the server-side of the master repository by directly
> > > enforcing the access control on keys, revisions, and certs during
> > > NETSYNC and even _ROLLING BACK_ the _WHOLE_ NETSYNC transaction in
> > > case an ACL fails. And I've now also developed an experimental
> > > implementation for this and I have written a little bit more about this
> > > stuff in my BLOG a few days ago (see the following URL for details:
> > > http://trainofthoughts.org/blog/2007/09/16/distributed-vcs-central-acl/).
> > > We are currently testing this stuff in practice with a few test
> > > repositories. Looks promising so far.
> >
> > You're going to have a problem with the transaction handling here --
> > the server does not and can not wrap a client connection into a single
> > transaction.  The problem is that the server is multiplexing across
> > multiple connections at once, but with sqlite (and RDBMSes generally,
> > to some extent) there is no way to have multiple parallel transactions
> > open at the same time, to keep separate the data that's arriving in
> > parallel from multiple clients.  So the server commits regularly.
>
> Hmmm... interesting point. Thanks for the hint. You're right, the
> concurrent incoming connections could make real trouble here. I've to
> investigate to see whether a workaround is possible or whether we really
> hit against the wall here. Many thanks for clarifying this point.

Ok, based on your valuable feedback we re-investigated today.
Here is our version 2 of the NETSYNC hook extension & abstraction for review.

We're now addressing the problem "How can we ensure that a revision is
not stored into the database at all in case an ACL hook determines that
one of its certificates break an ACL rule?" the following way:

- As we have learned, "mtn serve" is multiplexing its I/O. So, there
  is no direct correlation of the SQLite database transactions and the
  NETSYNC sessions and hence we cannot rely on the SQLite transactions
  to get rid of already (accidentally) received data.

- When we look at the situation in more detail, the problem actually is
  not that we have to rollback a whole NETSYNC _session_. Instead it
  would be sufficient if we can rollback the current logical NETSYNC
  _bundle_ consisting of the transmitted {file,delta}*,revision,cert*
  chunk. Unfortunately, in those NETSYNC transmissions the certs (which
  are the interesting ones for ACL) come last.

- To achieve the rollback we now temporarily PER SESSION queue
  the database operations resulting from such a bundle of received
  {file,delta}*,revision,cert* chunks before actually writing it to the
  database.

- In case any NETSYNC Lua hook denies the storage of some data we
  "rollback" at least the current _bundle_ by clearing the mentioned queue
  and dropping the NETSYNC session. This way we for instance never store a
  revision without its corresponding certs in case the certs cause a Lua
  hook to deny access to the database.

- Additionally, we perform the regular database checkpointing now at
  those "bundle" borders only.

To repeat what this stuff achieves:

1. 6 additional NETSYNC hooks which can control access (or just monitor
   data in real-time) during the NETSYNC protocol.

2. A useful Lua abstraction layer which allows one to flexibly and
   easily hook into _all_ NETSYNC related hooks, even from multiple Lua
   extensions in parallel. This way one can implement access control,
   mirroring, whatever Monotone Lua extensions without technical
   interference.

[The other parts like AAA and the generic Lua extensions you can
ignore at this time as these are strongly related but nevertheless
independent things].

More feedback?
                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com

PS: Please just ignore the "#if defined(RSE) ... #endif" stuff in the
    patch file. These are there just temporarily, of course. In case the
    stuff is worth to be included into Monotone upstream at some time,
    they will be removed, of course.

monotone-netsync.pod
Description: Text document

monotone-netsync.lua
Description: Text document

monotone-netsync.diff
Description: Text document