gitolite/doc/5-delegation.mkd

# delegating access control responsibilities

[Thanks to jeromeag for forcing me to think through this...]

----

In this document:

  * <a href="#lots_of_repos_lots_of_users">lots of repos, lots of users</a>
  * <a href="#splitting_up_the_set_of_repos_into_groups">splitting up the set of repos into groups</a>
  * <a href="#delegating_ownership_of_groups_of_repos">delegating ownership of groups of repos</a>
  * <a href="#security_philosophy_note">security/philosophy note</a>

----

<a name="lots_of_repos_lots_of_users"></a>

### 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.

<a name="splitting_up_the_set_of_repos_into_groups"></a>

### 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

<a name="delegating_ownership_of_groups_of_repos"></a>

### 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.

----

<a name="security_philosophy_note"></a>

### security/philosophy note

The delegation feature is meant only for access control rules, not pubkeys.
Adding/removing pubkeys is a much more significant event than changing branch
level permissions for people already on staff, and only the main admin should
be allowed to do it.

Gitolite's "userids" all live in the same namespace.  This is unlikely to
change, so please don't ask -- it gets real complicated to do otherwise.
Allowing delegated admins to add users means username collisions, which also
means security problems (admin-A creates a pubkey for Admin-B, thus gaining
access to all of Admin-B's stuff).

If you feel the need to delegate even that, please just go the whole hog and
give them separate gitolite instances!  It's pretty easy to setup the
*software* itself system-wide, so that many users can use it without all the
"easy install" fuss.  See the "system install / user setup" section in
doc/0-INSTALL.mkd for details.