Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations

From: Johan Sørensen <johan@johansorensen.com>
Date: Mar 14, 2009, 14:39 UTC
Message-ID: <9e0f31700903140739g26be7981lb0fa411cdd8029e6@mail.gmail.com>
In-Reply-To: <7vvdqcd1zh.fsf@gitster.siamese.dyndns.org>

On Sat, Mar 14, 2009 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> However, being paranoid is a good thing when we talk about instructions we
> give to the end users.  The site owner who uses this facility needs to be
> aware that the script is run as the same user that runs git-daemon, and
> that more than one instances of the script can be run at the same time.
> The script writer needs to be careful about using the same scratchpad
> location for the temporary files the script uses and not letting multiple
> instances of scripts stomping on each other's toes.  These things need to
> be documented.

Will expand the docs further.

> Do you run git-daemon from inetd, or standalone, by the way?

Standalone.

> I am wondering how well it would scale if you spawn an external "filter path"
> script every time you get a request.

A quick test of 250 consecutive requests with ls-remote to localhost
(all without the --verbose flag), slowest run:
- Baseline (no --filter-path agument): 3.39s

$ cat filter.c
#import "stdio.h"
int main (int argc, char const *argv[]) {
	printf("%s", "/existing.git\0");
	return 0;
}
- 3.84s

$ cat filter.rb
#!/usr/bin/ruby
print "/existing.git\0"
- 4.76s

So, obviously highly dependent on how long it takes the script to launch and how much work it does. And yes, neither of the above really does anything :) nor takes any increased cpu load into account

Another approach is to keep the external script running and feed it on stdin, but that would involve a bit more micro-management of the external process. I will revisit that idea if I find out that's needed.

> (by the way, "filter path" sounds as if it checks and conditionally
> denies access to, or something like that, which is not what you are using
> it for.  It is more about rewriting paths, a la mod_rewrite, and I think
> the option is misnamed)

Maybe --rewrite-script or --rewrite-command  instead?

Cheers, JS