"git daemon"

Guys,
 I've written a really simple TCP git daemon that normally listens on 
port "DEFAULT_GIT_PORT" aka 9418. It waits for a connection, and will just 
execute "git-upload-pack" when it gets one.

It's actually a bit more careful than that, in that there's a magic request-line that gives the command and what directory to upload, and it verifies that the directory is ok.

In particular, it verifies that the directory has the magic file "git-daemon-export-ok", and it will refuse to export any git directory that hasn't explicitly been marked for export this way.

What I'd ask people to check is how comfortable for example kernel.org would be to have one machine that runs this kind of service? I've tried very hard to set it up so that it doesn't have any security issues: the daemon can be run as "nobody", and it shouldn't ever even write to any files, although I guess we should do a full check of that.

In fact, it doesn't even really accept any user input except for the list of SHA1's that you give the upload which denote the "I have these" list. So I really think it should be hard to fool into doing anything bad, and the code isn't _that_ complicated, but hey, it's a daemon. They're always buggy, and there are always security issues.

Anyway, this would be a _wonderful_ interface for read-only updates, ie people pulling from my (and other peoples) git repositories.

		Linus

On Wed, 13 Jul 2005, Linus Torvalds wrote:

I guess I should say what the interface is, so that people don't have to read the sources to find out..

On the server side:

	# mark all repositories you want to export with the
	# "git-daemon-export-ok" file in the .git directory..
	#
	# .. and let the port (9418) through any firewalls etc,
	# of course

	git-daemon >& logfile &

(NOTE! "git-daemon" will not disassociate from any tty's or anything fancy like that.)

On the client side:

	git pull git://servername/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

And you're done.

(or "git clone", for that matter - I just fixed a one-liner that caused "clone" to not work, so make sure that you have a commit that says 'Fix the "close before dup" bug in clone-pack too').

If you want to use a different port number (maybe 9418 is some really 133t port, and google just doesn't know about it), you can give git-daemon a "--port=x" command line argument, and you can use

	git://servername:port/pathname

on the client side. At least that was my intention, I didn't actually test whether that worked (but the default port has been tested).

			Linus

Linus Torvalds wrote:

Since it can be run as a sequestered user, and we now have plenty of CPU horsepower on the download servers, it seems like it should be an entirely sane thing to do.

Is this thing meant to be run from inetd, or is it a "listen and fork" daemon? Especially the latter case, it absolutely *have* to have protections for:

- "SYN and run" DoS attacks;
- Too many connections from the same IP;
- Too many processes running total.

	-hpa

On Fri, 15 Jul 2005, H. Peter Anvin wrote:

Goodie.

It can do both, now (since earlier today). Use the "--inetd" flag if you run it from something like inetd that will have done the accept/fork for it. In that case the "--port=xxx" argument obviously doesn't make any sense.

There are "git-core-0.99.1" rpm (src, x86, ppc64 as usual) at

	http://www.kernel.org/pub/software/scm/git/

which are new enough that they already have the --inetd flag support.

Do you prefer just relying on inetd, or should I extend the server? inetd obviously involves an extra execve(), but on the other hand, it's a very very small program, so it's not like it's a huge expense (it does some very trivial parsing, and then it ends up executing "git-upload-pack").

Right now you're right - you definitely want to use inetd. I just realized that my built-in server leaves zombies around, for example.

On the security front:

I've still not audited the full source and quite frankly I'd like somebody else to do that since it's not only boring, but it's all my code, so I'm blind to any bugs anyway.

But I _have_ straced a full sequence of the daemon side of a "git pull" and grepped every "open()", and they were all O_RDONLY, and every read() from the incoming file descriptor was using the "packet-line" interface which is designed to be safe too (ie there are no possibilities of overflows there that I can see).

			Linus