I want to maintain my debian servers by pushing etc into gitolite.

The problem is that gitolite shouldn't be run as root and neither as a user that can get shell access into the system from the outside. However I need gitolite to interact with etckeeper in hooks and triggers (eg. make sure all pending changes to the working tree are committed and pushed into the bare gitolite repo before any git operations from an outside user take place) for which root access is required.

I'm wondering what would be a safe, simple and elegant way to solve this problem.

Obviously many solutions are possible, but i'm not that adept at linux sys administration, so I seek some inspiration. Possible solutions I have thought about:

  • have two different users and some messaging system (producer/consumer or a deamon) with gitolite leaving a task to be executed by the root user. (seems very complicated compared to the luxury of a git hook which is a shell script that can execute any commands, especially since I will need to wait for the exit code)

  • use setuid? Seems made for the task, but reading up on it, it seems dangerous and not very supported for shell scripts...

Can someone point me in the right direction?

Update: I ended up finding some answers to this question myself, so posted an answer below. Any other solutions/considerations more than welcome...

  • I apologize for asking but you said you were not very adept at sysadmin work: How are you anticipating using etckeeper? Is this different from your current usage? Are you planning on pushing changes to live /etc/'s from a remote machine? (similar to the way some people deploy code with git?) – dfc Apr 15 '14 at 1:18
  • Yes, rather than logging into the server via ssh and editing config files via the terminal, I have a local copy of the server etc, which I can comfortably work on with say sublime text and than push to gitolite which takes care of forwarding it to etckeeper. There are many conveniences in this, for example when I update the server I can always accept maintainers config versions, and then remerge my custom changes over that, resolving merge conflicts at home with meld... makes things alot more comfortable especially on slow connections where working over ssh is a pain. – user13666 Apr 15 '14 at 1:31

I found this guide titled: gitolite and etckeeper but it's untested by me.


In an effort to track changes on my many Linux boxes, I’ve installed etckeeper which tracks all changes to /etc. It comes with a nice hook into apt which autocommits anytime a package is installed.

In addition to keeping the changes in a git repo, I’ve started pushing to a central repository which is managed with gitolite. I’ve setup etckeeper with the following steps:

As root in /etc

  $ git config –global user.email root@jhulst.com
  $ git config –global user.name “Configuration Admin”
  $ git remote add origin git@jhulst.com:machineconf

Place git key in /root/.ssh.

As root:

  $ cd /etc/etckeeper/commit.d
  $ (echo ‘#!/bin/sh’ ; echo ‘git push origin’) > 99git-push
  $ chmod +x 99git-push
  $ git add .
  $ git commit -m “automatically push commits to backup repository”
  • Thanks, I had found no resources on the combination of these two tools. This might help somewhat, but doesn't cover everything. Right now I have gitolite do git add --all .;git commit -m"something"; git push; on etc before it excecutes any git command on the bare repo. That way I'm sure I won't have merge conflicts on the server when pushing. I suppose I could run a cron job that does these commands on a very regular basis to avoid having to do it from gitolite though... It would be a bit of a hack, but might be good enough. – user13666 Apr 15 '14 at 1:41
  • @nus - not sure if it bodes well for this approach or not that there is literally only this post I found, a couple of references to the combo in some dated forum posts, and your Q here on U&L. That tells me that this approach might not be a good way to go. But it doesn't hurt to try it. – slm Apr 15 '14 at 1:54
  • btw, just looked in etckeeper.conf and automatically pushing to a remote is a feature, so no need for the script from this blogpost. – user13666 Apr 15 '14 at 2:23

Ok, full moon is coming up and my sleep deprived mind starts to spin in creative overdrive. I think I have cracked the problem.

In the process I discovered a second major security issue and will discuss them both.


  • gitolite must be able to pull changes into /etc/.git as well as have them checked out. Thus it must have privileges, but as it is a software account that accepts ssh connections from outside, that poses a security risk.

  • the second issue is that by letting /etc pass under gitolite's nose, we give it the possibility to read and alter files that it shouldn't be able to. Gitolite should be no more than a transport protocol which is transparent to both ends. An untrusted middle (wo)man, and that is fortunately a very well investigated pattern in information security.


To allow gitolite to take some limited action with privileges, it is actually possible to just add it's user to the sudoers file and allow it to run just the scripts it must as root. sudoers allows you to add a hash to the rule to avoid doing verification based only on filename:

etcgit ALL=(root) NOPASSWD: sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ== /etc/gitolitetc/scripts/xxx.sh

This allow user etcgit to do just one thing, and that one thing is protected from tampering with a hash.

Now for the problem of gitolite reading and changing /etc, several solutions have been proposed for transparently encrypting git end-to-end. If they prove viable, that solves all at once.

If they don't prove viable, you can still omit certain files from the git repository to avoid gitolite reading them, and you can write a git hook that will only pull in commits that are signed of by the developer, which would mean your private pgp key is needed to get /etc/.git to accept a change. Mike Gerwitz has excellently demonstrated this on his blog including the scripts to check signatures as well as a thorough theoretical analysis.

As some esoteric other option yet to be checked with feasability, it might be possible to keep the bare repository that gitolite is supposed to control under root ownership and use sudoers to allow gitolite just the minimum necessary commands to do it's job of passing commit's back and forth, without actually being able to read the contents of the repository. I doubt this will be possible, but if it is, it has all the benefits and none of the disadvantages of encrypting the repositories.

Well, I feel that when I'll finally be done with configuring my server this will be material for a first blog post on my then to be brand new programming blog.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy