gitolite/doc/shell-games.mkd

avoiding the shell on the server

Gitolite now tries to prevent gitolite-admin push privileges from being used to obtain a shell on the server. This was not always the case (older gitolite did not make this distinction), but I've been moving towards this for a while now, and, while there could still be holes in that separation, they will be fixed as and when found.

Thus, settings that have security implications can be set only from the rc file, which needs to be edited directly on the server. And adding a new hook requires adding it to the gitolite clone and running easy install again, or gl-setup, if you used the server-side install method, both of which require shell access.

While this is great for my main target (corporate environments), some people don't like it. They want to do all of this from the gitolite-admin repo, because the security concern mentioned above does not bother them. They don't want to log on to the server to make a change in the rc file or don't want to run easy install to propagate a new set of hooks. In addition, they may want all of these animals versioned in the "gitolite-admin" repo itself, which certainly makes sense.

So here's how you might do that.

First, arrange to have all your special files added to the gitolite-admin repo. The best option is to keep all of this in a single subdirectory (let's call it "local" in our example). So your ~/.gitolite.rc might go into local/gitolite.rc, and all your local hooks into local/hooks etc. Add them, commit, and push.

Note: do not create any top level directory called "conf", "contrib", "doc", "hooks", or "src" -- those names are used by gitolite itself.

Second, create a post-update.secondary hook and place it in the gitolite clone's hooks/common directory, containing the following code:

#!/bin/bash

[ "$GL_REPO" = "gitolite-admin" ] || exit 0

[ -z "$GL_RC" ] && { echo "ENV GL_RC not set"; exit 1; }

GL_ADMINDIR=`$GL_BINDIR/gl-query-rc GL_ADMINDIR`

cp    $GL_ADMINDIR/local/gitolite.rc    $HOME/.gitolite.rc
cp -a $GL_ADMINDIR/local/hooks/*        $GL_ADMINDIR/hooks/common

/Full/Path/To/gl-install -q
    # the path should be the same as that for gl-auth-command in the
    # "command=" parameter of ~/.ssh/authorized_keys on the server

Don't forget to make it executable!

After this, run the upgrade instructions for the install method you used (just as if the post-update.secondary file you just created came from a gitolite software update).

All future changes to the rc file can be done via local/gitolite.rc in the admin repo, and hooks can be added to local/hooks.

Note: One quirk of how gitolite propagates hooks is that now this post-update.secondary exists in all normal repos also. Just ignore it; it's not doing any harm.

Warning: Nothing in gitolite removes hooks, so if you delete (or even rename) a script, it still stays on the server -- you'll have to delete them manually from the server.

---

So what's this actually doing?

Well, first, note that $GL_ADMINDIR contains files from both gitolite itself, as well as from the gitolite-admin repo. "conf/VERSION", "src", "doc", and "hooks" come from gitolite itself, while the other 2 files in "conf", and all of "keydir" come from the gitolite-admin repo. ("logs" doesn't come from anywhere).

In addition, any other files in the "master" branch of the gitolite-admin repo get checked out here, which in this case would mean the entire "local/" hierarchy you created above.

Now, since the "hooks/common" directory is coming from gitolite itself, clearly this is where the internal "install" routine expects to find new or updated hooks to propagate. So you just copy your local hooks (in the "local/hooks" directory) to "hooks/common" and run the installer again. Done!