165 lines
6.4 KiB
Markdown
165 lines
6.4 KiB
Markdown
## delegating access control responsibilities
|
|
|
|
In this document:
|
|
|
|
* <a href="#_lots_of_repos_lots_of_users">lots of repos, lots of users</a>
|
|
* <a href="#_how_to_use_delegation">how to use delegation</a>
|
|
* <a href="#_the_subconf_command">the subconf command</a>
|
|
* <a href="#_backward_compatibility">backward compatibility</a>
|
|
* <a href="#_security_notes">security notes</a>
|
|
* <a href="#_group_names">group names</a>
|
|
* <a href="#_delegating_pubkeys">delegating pubkeys</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. 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.
|
|
|
|
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. You can allow access control rules
|
|
for a set of repos to be specified in a **subconf** file and allow someone (a
|
|
**sub-admin**) to make changes within that file. (Note: sub-admins cannot
|
|
create or remove users).
|
|
|
|
<a name="_how_to_use_delegation"></a>
|
|
|
|
### how to use delegation
|
|
|
|
First, you group your repos however you want. In the example below, I'm
|
|
considering firefox and lynx (projects at the root of the gitolite server) as
|
|
well as *any* repo inside the `browsers` subdirectory, as members of the
|
|
`webbrowsers` group. Similarly for the others.
|
|
|
|
@webbrowsers = firefox lynx browsers/..*
|
|
@webservers = apache nginx servers/..*
|
|
@malwares = conficker storm ms/..*
|
|
# side note: if anyone objects, we claim ms stands for "metasploit" ;-)
|
|
|
|
Each of these groups is called a **subconf** from here on.
|
|
|
|
Then you designate a **sub-admin** to manage each subconf, and you ensure
|
|
(using the standard gitolite feature of restricting pushes by names of changed
|
|
files) that a sub-admin can make changes only to her subconf file and nothing
|
|
else.
|
|
|
|
For example, Alice is in charge of all web browser development projects.
|
|
Similarly, 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
|
|
|
|
# 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/subs/webbrowsers = alice
|
|
RW NAME/conf/subs/webservers = bob
|
|
RW NAME/conf/subs/malwares = mallory
|
|
|
|
Finally, you tell gitolite to pull in these files using the "subconf" command
|
|
|
|
subconf "subs/*.conf"
|
|
|
|
You can put this command anywhere in the main gitolite.conf file, but it's
|
|
best to put it at the end.
|
|
|
|
Now alice can clone the admin repo, add a file called `conf/subs/webbrowsers`
|
|
with whatever access rules she wants for the repositories under her control,
|
|
commit and push.
|
|
|
|
And that's really all there is to it.
|
|
|
|
<a name="_the_subconf_command"></a>
|
|
|
|
#### the subconf command
|
|
|
|
This command is much like the "include" command, but in addition it checks
|
|
that a subconf does not contain ACL rules for repos that are outside its
|
|
purview.
|
|
|
|
In the above example, the `webbrowsers` subconf file can only have access
|
|
control lines for firefox, lynx, and anything under "browsers/" because those
|
|
are the elements of the `@webbrowsers` group. (This is checked using a regex
|
|
match, which is why "anything under browsers/" is written `browsers/..*`)
|
|
|
|
In more precise terms:
|
|
|
|
* the subconf name is simply the basename of the conf file, without the
|
|
.conf extension, and
|
|
* the elements of an `@` group of the same name are then used to limit what
|
|
repos the subconf can have ACL lines for.
|
|
|
|
(Additional notes: it can also contain lines for an actual repo called
|
|
`webbrowsers`, or, in big-config mode, for a group called `@webbrowsers`).
|
|
|
|
<a name="_backward_compatibility"></a>
|
|
|
|
#### backward compatibility
|
|
|
|
For backward compatibility, if no `subconf` commands have been seen at the end
|
|
of processing the main config file, gitolite pretends you appended
|
|
|
|
subconf "conf/fragments/*.conf"
|
|
|
|
to the end of the file.
|
|
|
|
<a name="_security_notes"></a>
|
|
|
|
### security notes
|
|
|
|
<a name="_group_names"></a>
|
|
|
|
#### group names
|
|
|
|
You can use "@group"s defined in the main config file but do not attempt to
|
|
redefine or extend them in your own subconf file. If you must extend a group
|
|
(say `@foo`) defined in the main config file, do this:
|
|
|
|
@myfoo = @foo
|
|
# now do whatever you want with @myfoo
|
|
|
|
Group names you define in your subconf will not clash even if the exact same
|
|
name is used in another subconf file, so you need not worry about that.
|
|
|
|
<a name="_delegating_pubkeys"></a>
|
|
|
|
#### delegating pubkeys
|
|
|
|
Short answer: not gonna happen.
|
|
|
|
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 sub-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; see the root
|
|
install method in the install document.
|