Gitolite, git-daemon and SELinux

Letting gitolite, git-daemon, gitweb and SELinux play well together needs some careful thought. Although most of the hard work is already done you still need to tweak the permissions a little. Especially when the git repository is not stored under /var/lib/gitolite. In the following discussion I assume that the gitolite repository is installed under /home/git or /home/gitolite.

The gitolite installation manual does a good job of giving a step by step instruction. What it does not describe is the SELinux settings needed to let it work together. The following instructions have been performed on a Fedora 16 system, but should hold true for any other SELinux enabled system.

Gitweb, git-daemon and SELinux

Gitolite plays well together with gitweb. However there are a couple of caveats you need to know.

To enable gitweb to browse the gitolite user directory you must follow the instructions from the gitolite manual. Which among other things tell you to perform the following:

Add git (or gitolite) user to the httpd group:

$ usermod -a -G httpd git

Allow the group to browse the git home directory.

$ chmod g+rx /home/git

In addition to that you must allow the httpd daemon to browse the git home directory.

Check the SELinux permissions for httpd and git:

$ getsebool -a | grep httpd

$ getsebool -a | grep git

And especially these settings:

$ getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off

$ getsebool git_system_enable_homedirs
git_system_enable_homedirs --> off

Make sure the httpd daemon can browse the directory /home/git (or /home/gitolite) with:

$ setsebool -P httpd_enable_homedirs on

Do the same for git:

$ setsebool -P git_system_enable_homedirs on

The -P option of 'setsebool' ensures that this settings is retained over reboots of the server.

Another issue is that each time you add a new repository to conf/gitolite.conf, commit it to your working copy and then push it to the remote repository, then the file 'project_list' gets rewritten and the SELinux permissions are put back to default. I have not found a way to automate this yet, so it needs to be done manually as root each time a new repository is added:

$ chcon -t httpd_sys_content_t projects_list

A workaround for this issue is using restorecond. It uses inotify to check changes on the files mentioned in /etc/selinux/restorecond.conf and restores its selinux context. Before using this the file projects.list should have the correct context associated with it.

Change the selinux context for /home/git/projects.list to httpd_sys_content_t with semange:

$ semanage fcontext -a -t httpd_sys_content_t /home/git/projects.list

The git CGI script needs to be able to browse the directory /home/git/repositories. Make sure it can by changing the default selinux context to 'git_sys_content_t'. This will allow git-daemon to browse the repositories too. Configure git-daemon from /etc/xinetd./git

$ semanage fcontext -a -t git_sys_content_t "/home/git/repositories(/.*)?

Test if the change was successfull with restorecon

$ restorecon -v /home/git/projects.list

$ restorecon -R -v /home/git/repositories

Install the package with restorecond using yum.

$ yum install policycoreutils-restorecond

Edit /etc/selinux/restorecond.conf and add /home/git/projects.list and /home/repositories/* to the list

Finally make sure restorecond will be started by systemd at every system boot and start it manually for the first time.

$ systemctl enable restorecond.service

$ systemctl start restorecond.servcie


The article has been updated to include the -P option to setsebool This instructs SELinux to write this setting to the policy files on disk. This way it is retained over reboots of the server.

The discussion is updated with a workaround for updating the selinux context for /home/git/projects.list. The idea was suggested by David Quigley.

Added information on the correct selinux security context for the repository directory itself. In this case /home/git/repositories