(For more resources related to this topic, see here.)
Access Control example with Gitolite
We will see how simple Access Control can be with Gitolite. First, here’s an example where the junior developers (let’s call them Alice and Bob here) should be prevented from rewinding or deleting any branches, while the senior developers (Carol and David) are allowed to do so:
Gitolite uses a plain text file to specify the configuration, and these access rules are placed in that file.
repo foo RW = alice bob RW+ = carol david
You probably guessed that the RW stands for read and write. The + in the second rule stands for force, just as it does in the push command, and allows you to rewind or delete a branch.
Now, suppose we want the junior developers to have some specific set of branches that they should be allowed to rewind or delete, a sort of “sandbox”, if you will. The following command will help you to implement that:
RW+ sandbox/ = alice bob
Alice and Bob can now push, rewind, or delete any branches whose names start with sandbox/.
Access Control at the repository level is even easier, and you may even have guessed what that looks like:
repo foo RW+ = alice R = bob repo bar RW+ = bob R = alice repo baz RW+ = carol R = alice bob
As you can see, you have three users with different access permissions for each of the three repositories. Doing this using the file systems’ permissions mechanisms or POSIX ACLs would be doable, but quite cumbersome to set up and to audit/review.
Sampling of Gitolite’s power features
The access control examples show the most commonly used feature of Gitolite, the repository and branch level access control, but of course Gitolite has many more features. In this article, we will briefly look at a few of them.
Creating groups
Gitolite allows you to create groups of users or repositories for convenience. Think back to Alice and Bob, our junior developers. Let’s say you had several rules that Alice and Bob needed to be mentioned in. Clearly, this is too cumbersome; every time a new developer joined the team, you’d have to change all the rules to add him or her.
Gitolite lets you do this by using the following command:
@junior-devs = alice bob
Later, it lets you do this by using the following command:
repo foo RW = @junior-devs RW+ = carol david RW+ sandbox/ = @junior-devs
This allows you to add the junior developer in just one place at the top of the configuration file instead of potentially several places all over. More importantly, from the administrator’s point of view, it serves as excellent documentation for the rules themselves; isn’t it easier to reason about the rules when a descriptive group name is used rather than actual usernames?
Personal branches
Gitolite allows the administrator to give each developer a unique set of branches, called personal branches, that only he or she can create, push, or delete. This is a very convenient way to allow quick backups of work-in-progress branches, or share code for preliminary review.
We saw how the sandbox area was defined:
RW+ sandbox/ = alice bob
However, this does nothing to prevent one junior developer from accidentally wiping out another’s branches. For example, Alice could delete a branch called sandbox/bob/work that Bob may have pushed. You can use the special word USER as a directory name to solve this problem:
RW+ sandbox/USER/ = alice bob
This works as if you had specified each user individually, like this:
RW+ sandbox/alice/ = alice RW+ sandbox/bob/ = bob
Now, the set of branches that Alice is allowed to push is limited to those starting with sandbox/alice/, and she can no longer push or delete a branch called, say, sandbox/bob/work.
Personal repositories
With Gitolite, the administrator can choose to let the user create their own repositories, in addition to the ones that the administrator themselves creates. For this example, ignore the syntax and just focus on the functionality:
repo dev/CREATOR/[a-z].* C = @staff RW+ = CREATOR
This allows members of the @staff group to create repositories whose names match the pattern supplied, which just means dev/<username>/<anything starting with a lowercase alphabetic character>. For example, a user called alice will be able to create repositories such as dev/alice/foo and dev/alice/bar.
Gitolite and the Git control flow
Conceptually, Gitolite is a very simple program. To see how it controls access to a Git repository, let us first look at how control flows from the client to the server in a normal git operation (say git fetch) when using plain ssh :
When the user executes a git clone, fetch, or push, the Git client invokes ssh, passing it a command (either git-upload-pack or git-receive-pack, depending on whether the user is reading or writing). The local ssh client passes this to the server, and assuming authentication succeeds, that command gets executed on the server.
With Gitolite installed, the ssh daemon does not invoke the git-upload-pack or git-receive-pack directly. Instead, it calls a program called gitolite-shell, which changes the control flow as follows:
First, notice that nothing changes on the Git client side in anyway; the changes are only on the server side. In fact, unless an access violation happens and an error message needs to be sent to the user, the user may not even know that Gitolite is installed!
Second, notice the red link from Gitolite’s shell program to the git-upload-pack program. This call does not happen if Gitolite determines that the user does not have the appropriate access to the repo concerned. This access check happens for both read (that is, git fetch and git clone commands) and write (git push) operations; although for writes, there are more checks that happen later.
Summary
In this article, we learned about Access control with Gitolite. We also went through sampling of Gitolite’s power features. We also covered the Git control flow.
Resources for Article:
Further resources on this subject:
- Parallel Dimensions – Branching with Git [Article]
- Using Gerrit with GitHub [Article]
- Issues and Wikis in GitLab [Article]
