[Monotone-devel] permission (was Re: version 1.14 fails "make check")

[graydon hoare]

On 16 Aug 2004 13:47:11 +0200, Peter Simons <address@hidden> wrote:

> What about ANCESTOR, for instance? Won't trusted ANCESTOR
> certificates be used for 3-way merges, regardless of the
> branch they are in? In that case, trusting (or not trusting)
> BRANCH won't be good enough.

ancestry certs are going away on the changeset branch. the
ancestry graph in the future will always describe the history
of how it was made. indeed, each node contains (via chained hashes)
a summary of how it came to be; including such a node of that
graph into a branch is an implicit statement that its history
is agreeable. nodes become historical paths, and yes, 3-way
merges will accept any ancestor they find. you have to be
a bit more careful about whose history you certify, because you
are indeed giving a certified node a say in future merges.

it is possible that this will prove to be a security risk, and
we will need to make an option on merge such as --cross-branches,
and make the default behavior *not* cross branches when searching
for ancestors. I'm willing to accept that penalty to get the
usability improvement of not dealing with the potential problem of
disagreeing branch and ancestry certs. that is a nightmare.

alas, that doesn't answer the general "permission" problem.

I should have stuck my fingers into this conversation a while ago,
but it's been a strange weekend. anyways, there has been some talk
on IRC and in person about monotone's "permission" system over the
past few weeks, and I've been inching towards an improved design.
the current picture in my mind is as follows:

 - put a file called .mt-acl in the root of a file tree. this
   file contains mappings between keys and path globs. the keys
   are "permitted" to change files matching the path globs.

 - monotone still uses a lua hook (clients with really odd
   preferences can change it) but by default it evaluates a
   revision R as an acceptable member of a branch B iff:

     - for each change C in the revision, there exists a
       [glob,key] pair [G,K] in the .mt-acl file of the
       pre-state of the revision, such that C matches
       G and K signed a branch cert binding R into B.

     - extension: AND and OR operators in the "key" syntax
       such that you can do code review groups and
       prerequisite combinations (tester AND (bob OR alice)),
       or perhaps even some n-of-k selection.

 - you make a new hook called "get_branch_managers(b)" which
   returns a key list, or an extended AND/OR set or something,
   which defines the keys which are allowed to mess with the
   .mt-acl file. the users still have to configure this
   (or perhaps cache it in their database or such)

afaict this has a bunch of desirable implications:

 - each revision is self-describing in terms of its permissions
   at a  particular point in history. if bob was allowed to
   write into the foo/bar directory for a while, 6 months ago,
   that fact is still recorded even if bob can no longer write
   anywhere. say he was a contractor who is no longer working
   on the project.

 - netsync can evaluate these things on the fly because they
   are self-describing. it still probably makes sense for
   netsync to be a little cautious about incoming connections
   which might DoS it, but it might be possible to make it more
   willing to operate "without configuration", deciding to
   accept for example all connections from anyone listed in the
   .mt-acl file of the heads of any branch it is serving, and
   throwing out any changesets which are "no good" under the
   more detailed ACL rules above.

 - it adds a modest amount of "social cohesion power" against
   people making unwanted forks without making new branch names:
   monotone will ignore their fork until either they make a new
   branch name which they are a manager of, or they convince
   one of the people listed (immutably) in the pre-state ACL of
   their fork to sign their fork into the branch.

   (their own monotone can be convinced of anything, of course,
    but they have to declare themselves manager of the branch
    first, which most other users will decline to do)

 - it makes the life of a contributor easier, as they have a
   well defined pair of alternatives they need to achieve in
   order to make their changes "acceptable". they know as soon
   as they try to commit whether it'll go into "accepted" or
   "contrib which someone else needs to review".

now let us watch as njs tears the idea to shreds :)

-graydon