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.


> 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

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


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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to