32056e0b7f
There were 2 problems with rule sequencing.
Eli had a use case where everyone is equal, but some are more equal than
the others ;-) He wanted a way to say "everyone can create repos under
their own names, but only some people should be able to rewind their
branches".
Something like this would be ideal (follow the rules in sequence for
u1/u2/u3/u4, and you will see that the "deny" rule kicks in to prevent
u1/u2 from being able to rewind, although they can certainly delete
their branches):
@private-owners = u1 u2
@experienced-private-owners = u3 u4
repo CREATOR/.*
C = @private-owners @experienced-private-owners
RWD = CREATOR
RW = WRITERS
R = READERS
- = @private-owners
RW+D = CREATOR
In normal gitolite this doesn't work because the CREATOR rules (which
get translated to "u1" at runtime) end up over-writing the "deny" rule
when u1 or u2 are the creators. This over-writing happens directly at
the "do compiled.pm" step.
With big-config, this does not happen (because @private-owners does not
get expanded to u1 and u2), but the problem remains: the order of
picking up elements of repo_plus and user_plus is such that, again, the
RW+D wins (it appears before the "-" rule).
We fix all that by
- making CREATOR complete to more than just the creator's name (for
"u1", it now becomes "u1 - wild", which is actually illegal to use
for real so there's no possibility of a name clash!)
- maintaining a rule sequence number that is used to sort the rules
eventually applied (this also resulted in the refex+perm hash
becoming a list)
|
||
|---|---|---|
| conf | ||
| contrib | ||
| doc | ||
| hooks | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| Makefile | ||
| README.mkd | ||
gitolite
[Update 2009-10-28: apart from all the nifty new features, there's now an "easy install" script in the src directory. This script can be used to install as well as upgrade a gitolite install. Please see the INSTALL document for details]
Gitolite is a rewrite of gitosis, with a completely different config file that allows (at last!) access control down to the branch level, including specifying who can and cannot rewind a given branch.
In this document:
- what
- why
- extra features
- security
- contact and license
what
Gitolite allows a server to host many git repositories and provide access to
many developers, without having to give them real userids on the server. The
essential magic in doing this is ssh's pubkey access and the authorized_keys
file, and the inspiration was an older program called gitosis.
Gitolite can restrict who can read from (clone/fetch) or write to (push) a
repository. It can also restrict who can push to what branch or tag, which is
very important in a corporate environment. Gitolite can be installed without
requiring root permissions, and with no additional software than git itself
and perl. It also has several other neat features described below and
elsewhere in the doc/ directory.
why
I have been using gitosis for a while, and have learnt a lot from it. But in a typical $DAYJOB setting, there are some issues:
- it's not always Linux; you can't just "urpmi gitosis" (or yum or apt-get) and be done
- often, "python-setuptools" isn't installed (and on a Solaris9 I was trying to help remotely, we never did manage to install it eventually)
- you don't have root access, or the ability to add users (this is also true for people who have just one userid on a hosting provider)
- the most requested feature (see below) had to be written anyway
All of this pointed to a rewrite. In perl, naturally :-)
extra features
The most important feature I needed was per-branch permissions. This is pretty much mandatory in a corporate environment, and is almost the single reason I started thinking about rolling my own gitosis in the first place.
It's not just "read-only" versus "read-write". Rewinding a branch (aka "non
fast forward push") is potentially dangerous, but sometimes needed. So is
deleting a branch (which is really just an extreme form of rewind). I needed
something in between allowing anyone to do it (the default) and disabling it
completely (receive.denyNonFastForwards or receive.denyDeletes).
Here're some more features. All of them, and more, are documented in detail here.
- simpler, yet far more powerful, config file syntax, including specifying gitweb/daemon access. You'll need this power if you manage lots of users+repos+combinations of access
- apart from branch-name based restrictions, you can also restrict by
file/dir name changed (i.e., output of
git diff --name-only) - config file syntax gets checked upfront, and much more thoroughly
- if your requirements are still too complex, you can split up the config file and delegate authority over parts of it
- easier to specify gitweb owner, description and gitweb/daemon access
- easier to sync gitweb (http) authorisation with gitolite's access config
- more comprehensive logging [aka: management does not think "blame" is just a synonym for "annotate" :-)]
- "personal namespace" prefix for each dev
- migration guide and simple converter for gitosis conf file
- "exclude" (or "deny") rights at the branch/tag level
- specify repos using patterns (patterns may include creator's name)
- define powerful operations on the server side, even github-like forking
security
Due to the environment in which this was created and the need it fills, I consider this a "security" program, albeit a very modest one.
For the first person to find a security hole in it, defined as allowing a normal user (not the gitolite admin) to read a repo, or write/rewind a ref, that the config file says he shouldn't, and caused by a bug in code that is in the "master" branch, (not in the other branches, or the configuration file or in Unix, perl, shell, etc.)... well I can't afford 1000 USD rewards like djb, so you'll have to settle for 5000 INR (Indian Rupees) as a "token" prize :-)
However, there are a few optional features (which must be explicitly enabled
in the RC file) where I just haven't had the time to reason about security
thoroughly enough. Please read the comments in conf/example.gitolite.rc for
details, looking for the word "security".
contact and license
Gitolite is released under GPL v2. See COPYING for details.
sitaramc@gmail.com mailing list: gitolite@googlegroups.com