98 lines
4.2 KiB
Markdown
98 lines
4.2 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 webbrowser_repos = alice
|
|
RW webserver_repos = bob
|
|
RW malware_repos = mallory
|
|
|
|
As you can see, **for each repo group** you want to delegate authority over,
|
|
there's a **branch with the same name** in the `gitolite-admin` repo. If you
|
|
have write access to that branch, you are allowed to define rules for repos in
|
|
that repo group.
|
|
|
|
In other words, we use gitolite's per-branch permissions to "enforce" the
|
|
separation between the delegated configs!
|
|
|
|
Here's how to use this in practice:
|
|
|
|
* Alice clones the `gitolite-admin` repo, creates (if not already created) and
|
|
checks out a new branch called `webbrowser_repos`, and adds a file called
|
|
`conf/fragments/webbrowser_repos.conf` in that branch
|
|
|
|
* (the rest of the contents of that branch do not matter; she can keep
|
|
all the other files or delete all of them -- it doesn't make any
|
|
difference. Only that one specific file is used).
|
|
|
|
* 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 this branch 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.
|