On Tue, Aug 14, 2012 at 10:06 AM, Junio C Hamano <gits...@pobox.com> wrote: > Shawn Pearce <spea...@spearce.org> writes: > >> Parsing the request line of git-daemon is easy. But we could make it >> easier. An alternative arrangement would be to add a new command line >> flag to git daemon like --command-filter that names an executable >> git-daemon will invoke after parsing the request line. It can pass >> along the client IP address, command request, repository name, and >> resolved repository path, and tie stdin/stdout to the client. This >> binary can decide to exec the proper git binary for the named command, >> or just exit to disconnect the client and refuse service. This makes >> it simple for a tool like gitolite to plug into the git-daemon >> authorization path, without needing to be the network daemon itself, >> worry about number of active connection slots, etc. > > I think that is a good direction to go in, except that I am unsure > what kind of conversation do you want to allow between the "command > filter" helper and the client by exposing standard input and output > stream to to the helper.
Sorry, I was thinking the helper would exec the git command, and thus pass along the stdin/stdout socket. > If the client side has a matching "pre > negotiate command" helper support, then presumably the helpers can > discuss what Git protocol proper does not care about before deciding > to allow the connection go through, but until that happens, opening > the stdio streams up to the helper sounds like an accident waiting > to happen to me (e.g. "fetch-pack" connects, the server side helper > reads the first pkt-line from the client, says "OK, you may proceed" > to the daemon, then the daemon spawns the "upload-pack", which will > obviously see a corrupt request stream from "fetch-pack"). But seeing this, yes, that is a bad idea. Better to treat that like a hook, where exit status 0 allows the connection to continue, and exit status non-zero causes the connection to be closed. Maybe with an error printed to stderr (if any) being echoed first to the client if possible using the ERR formatting notation. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
