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