Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: [PATCH] Implement ACL module architecture and sample MySQL ACL module

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:29

Shawn Pearce [off-list ref] 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").
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help