Re: "git daemon"

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 16, 2005, 03:04 UTC
Message-ID: <Pine.LNX.4.58.0507151945370.19183@g5.osdl.org>
In-Reply-To: <42D86B92.7010303@zytor.com>

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.

Show 6 quoted lines

> 		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