e7962e5eda
I know hardly anyone is using delegation, but if you find yourself
locked out from pushing because of this one little thing, do this:
* on your gitolite-admin clone, add the required lines per this patch,
and commit
* on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and
delete the following line
'NAME_LIMITS' => 1
from the entry for "gitolite-admin" (if you don't know what that
means delete *all* such lines) and save the file
* back on your admin repo clone, do a push
100 lines
4.4 KiB
Markdown
100 lines
4.4 KiB
Markdown
# delegating access control responsibilities
|
|
|
|
[Thanks to jeromeag for forcing me to think through this...]
|
|
|
|
### lots of repos, lots of users
|
|
|
|
Gitolite tries to make it easy to manage access to lots of users and repos,
|
|
exploiting commonalities wherever possible. (The example in [this
|
|
section][ss] should give you an idea). As you can see, it lets you specify
|
|
bits and pieces of the access control separately -- i.e., *all* the access
|
|
specs for a certain repo need not be together; they can be scattered, which
|
|
makes it easier to manage the sort of slice and dice needed in that example.
|
|
|
|
[ss]: http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#simpler_syntax
|
|
|
|
But eventually the config file will become too big. If you let only one
|
|
person have control, he could become a bottleneck. If you give it to multiple
|
|
people, they might make mistakes or stomp on each others' work accidentally.
|
|
|
|
The best way is to divide up the config file and give parts of it to different
|
|
people.
|
|
|
|
Ideally, we would delegate authority for *groups* of repos, not individual
|
|
repos, otherwise it doesn't scale. It would also be nice if we could prevent
|
|
an admin from creating access rules for *any* repo in the system -- i.e., set
|
|
limits on what repos he can control. This would be a nice "security" feature.
|
|
|
|
Delegation offers a way to do all that. Note that delegated admins cannot
|
|
create or remove users, not can they define new repos. They can only define
|
|
access control rules for a set of repos they have been given authority for.
|
|
|
|
----
|
|
|
|
It's easier to show how it all works with an example instead of long
|
|
descriptions.
|
|
|
|
### splitting up the set of repos into groups
|
|
|
|
To start with, recall that gitolite allows you to specify **groups** (of users
|
|
or repos, same syntax). So the basic idea is that the main config file
|
|
(`conf/gitolite.conf` in your admin repo clone) will specify some repo groups:
|
|
|
|
# group your projects/repos however you want
|
|
@webbrowser_repos = firefox lynx
|
|
@webserver_repos = apache nginx
|
|
@malware_repos = conficker storm
|
|
|
|
# any other config as usual, including access control lines for any of the
|
|
# above projects or groups
|
|
|
|
### delegating ownership of groups of repos
|
|
|
|
Once the repos are grouped, give each person charge of one or more groups.
|
|
For example, Alice may be in charge of all web browser development projects,
|
|
Bob takes care of web servers, and Mallory, as [tradition][abe] dictates, is
|
|
in charge of malware ;-)
|
|
|
|
[abe]: http://en.wikipedia.org/wiki/Alice_and_Bob#List_of_characters
|
|
|
|
You do this by adding branches to the `gitolite-admin` repo:
|
|
|
|
# the admin repo access was probably like this to start with:
|
|
repo gitolite-admin
|
|
RW+ = sitaram
|
|
# now add these lines to the config for the admin repo
|
|
RW = alice bob mallory
|
|
RW+ NAME/ = sitaram
|
|
RW NAME/conf/fragments/webbrowser_repos = alice
|
|
RW NAME/conf/fragments/webserver_repos = bob
|
|
RW NAME/conf/fragments/malware_repos = mallory
|
|
|
|
This uses gitolite's ability to restrict pushes by file/dir name being changed
|
|
-- the syntax you see above ensures that, while "sitaram" does not have any
|
|
NAME based restrictions, the other 3 users do. See `conf/example.conf` for
|
|
syntax and notes.
|
|
|
|
As you can see, **for each repo group** you want to delegate authority over,
|
|
there's a rule for a **corresponding file** in `conf/fragments` in the
|
|
`gitolite-admin` repo. If you have write access to that file, you are allowed
|
|
to define rules for repos in that repo group.
|
|
|
|
In other words, we use gitolite's file/dir NAME-based permissions to "enforce"
|
|
the separation between the delegated configs!
|
|
|
|
Here's how to use this in practice:
|
|
|
|
* Alice clones the `gitolite-admin` repo, and adds a file called
|
|
`conf/fragments/webbrowser_repos.conf`
|
|
|
|
* she writes in this file any access control rules for the "firefox" and
|
|
"lynx" repos. She should not write access rules for any other project --
|
|
they will be ignored
|
|
|
|
* Alice then commits and pushes to the `gitolite-admin` repo
|
|
|
|
Naturally, a successful push invokes the post-update hook that the admin repo
|
|
has, which eventually runs the compile script. The **net effect** is as if
|
|
you appended the contents of all the "fragment" files, in alphabetical order,
|
|
to the bottom of the main file.
|