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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 14, 2012 at 10:06 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]