"git daemon"

"git daemon"

[Linus Torvalds]

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

Re: "git daemon"

[Linus Torvalds]

On Wed, 13 Jul 2005, Linus Torvalds wrote:
> 
> Anyway, this would be a _wonderful_ interface for read-only updates, ie 
> people pulling from my (and other peoples) git repositories.

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

Re: "git daemon"

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> 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.
> 

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

Re: "git daemon"

[Linus Torvalds]

On Fri, 15 Jul 2005, H. Peter Anvin 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.

Goodie.

> Is this thing meant to be run from inetd, or is it a "listen and fork" 
> daemon?

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.

> 		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.

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