All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Shawn Pearce <spearce@spearce.org>
Cc: Michal Novotny <minovotn@redhat.com>, git@vger.kernel.org
Subject: Re: [PATCH] Implement ACL module architecture and sample MySQL ACL module
Date: Tue, 14 Aug 2012 10:06:37 -0700	[thread overview]
Message-ID: <7vsjbp768y.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAJo=hJtYz3OX1C6HS7ivhJKBOSg=Ex3rKEdTYSbcDfFT1Jh4hw@mail.gmail.com> (Shawn Pearce's message of "Tue, 14 Aug 2012 09:27:19 -0700")

Shawn Pearce <spearce@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").

  reply	other threads:[~2012-08-14 17:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-14  9:59 [PATCH] Implement ACL module architecture and sample MySQL ACL module Michal Novotny
2012-08-14 16:12 ` Junio C Hamano
2012-08-14 16:27   ` Shawn Pearce
2012-08-14 17:06     ` Junio C Hamano [this message]
2012-08-14 17:26       ` Shawn Pearce
2012-08-14 18:37         ` Junio C Hamano
2012-08-15  5:12           ` [PATCH] daemon: --access-hook option Junio C Hamano
2012-08-15 14:08             ` Shawn Pearce
2012-08-21 10:57             ` Michal Novotny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vsjbp768y.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=minovotn@redhat.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.