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