Using apache authentication with gitweb, gitosis – repository access control

gitosis is a tool for simple hosting of git repositories and managing access to them. gitweb has capabilities to control which repositories are listed on the project list page – $strict_export, $export_auth_hook and some other friends. in my case, everyone accessing web resources are authenticating through apache, which in turn connects to an LDAP server.

Here is a guide for setting up gitosis.

Q: how to provide gitweb access only to those repositories to which the apache user has been granted access in gitosis.conf?

A: use $export_auth_hook in /etc/gitweb.conf.

This is modified source of gitweb_auth.

Make sure you match up your Apache names, ssh public keyfile names and gitosis ‘writable’ names.

Note: you may want to check out gitolite, an enhanced gitosis.

Last Updated by LK on 23.01.10 @ 00:32  | Comments4 Comments

Tags: , , , , , ,

Comments:

Hi,

Sorry; I live in India and was asleep at the time you came on #git (I assume it was you) and mentioned this.

The way gitolite is designed, doing this boils down to 2 things in your subroutine:

– “do” or “require” a file called ~/.gitolite/conf/gitolite.conf-compiled.pm (this contains just one hash called %repos that was created at “compile” time; more on this below)
– then check if this key exists: $repos{$projectname}{R}{$username} (where username and projectname are as defined in your code above; you still need those code pieces that setup those variables of course).

That’s it! No parsing of any file the way you’re doing now :-)

Gitolite has a slightly different way of dealing with access. Firstly, it’s access config is much, much, more flexible and powerful than the WIndows-ini style that gitosis uses. But the more important thing from your point of view is that parsing the access config is done only once, when you make a change, commit, and push. This “compile” step (as I call it) produces a hash and writes that hash out to a file.

My objective is that the “run time” (loosely speaking, the parts that come into play in deciding whether someone has access) should *not* do any parsing or complex stuff. They only read that hash and check for appropriate keys; that’s it. It has to be as simple as that.

[At work, I might have a need to auditably prove the access controls work as claimed, and it is easier to do that in two steps. In fact the auditors need not worry about the compile at all -- at any time that "...compiled.pm" file mentioned above is all they need to check if they want to be sure, and that contains just one hash, as I said.]

Anyway the end result is that *you* (in your gitweb auth subroutine) need not parse anything. It’s all done for you and sitting in a nice clean perl hash :-)

PS: I wish I could claim credit for anticipating this when I designed gitolite :-) But this is just luck — my design was driven entirely by the auditability issues I described earlier!

By Sitaram on 10.27.09 04:35

Hello,

My previous comment seems to have disappeared (or is awaiting moderation). Meanwhile, I have added this item to my documentation, including sample code (untested, but should work), at http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd#gitwebauth

Thank you.

Sitaram

By Sitaram on 10.27.09 07:31

why the heck did I write % instead of &… oh well you get the picture, please fix it and purge my comments :)

while(<FILE>) {

By Alex Alexander on 12.30.09 16:53

i’m going to gist this snippet.

edit: DONE, check post.

By LK on 01.08.10 14:20

RSS feed for comments on this post. TrackBack URI


Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:

(required)

(required)