[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] permission (was Re: version 1.14 fails "make check")
From: |
graydon hoare |
Subject: |
[Monotone-devel] permission (was Re: version 1.14 fails "make check") |
Date: |
Mon, 16 Aug 2004 12:21:51 -0400 |
User-agent: |
Opera M2/7.53 (Linux, build 737) |
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
- [Monotone-devel] Re: version 1.14 fails "make check", (continued)
- [Monotone-devel] Re: version 1.14 fails "make check", graydon hoare, 2004/08/09
- Re: [Monotone-devel] Re: version 1.14 fails "make check", Richard Levitte - VMS Whacker, 2004/08/09
- [Monotone-devel] Re: version 1.14 fails "make check", Peter Simons, 2004/08/09
- Re: [Monotone-devel] Re: version 1.14 fails "make check", Richard Levitte - VMS Whacker, 2004/08/09
- [Monotone-devel] Re: version 1.14 fails "make check", Peter Simons, 2004/08/09
- Re: [Monotone-devel] Re: version 1.14 fails "make check", Richard Levitte - VMS Whacker, 2004/08/09
- [Monotone-devel] Re: version 1.14 fails "make check", Peter Simons, 2004/08/15
- Re: [Monotone-devel] Re: version 1.14 fails "make check", Richard Levitte - VMS Whacker, 2004/08/16
- [Monotone-devel] Re: version 1.14 fails "make check", Peter Simons, 2004/08/16
- Re: [Monotone-devel] Re: version 1.14 fails "make check", Richard Levitte - VMS Whacker, 2004/08/16
- [Monotone-devel] permission (was Re: version 1.14 fails "make check"),
graydon hoare <=
- Re: [Monotone-devel] Re: version 1.14 fails "make check", Derek Scherger, 2004/08/09
- [Monotone-devel] Re: version 1.14 fails "make check", Derek Scherger, 2004/08/09