git-daemon breakage in 1.5.4

> I just noticed that my copy of git-daemon running from xinetd on  
> Red Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.
>
> Nothing printed to the logs on the server side: it simply hangs up.  
> By connecting via telnet I've confirmed that git-daemon is running  
> and does accept the initial connection.
>
> The verdict according to "git bisect" is that  
> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:
>
> Does that look like it might be the issue? Anyone familiar with  
> that part of the code care to comment? Any other info I can provide  
> that might shed light on the problem?

>
> On Feb 5, 2008, at 7:39 AM, Wincent Colaiuta wrote:
>
>> I just noticed that my copy of git-daemon running from xinetd on  
>> Red Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.
>>
>> Nothing printed to the logs on the server side: it simply hangs up.  
>> By connecting via telnet I've confirmed that git-daemon is running  
>> and does accept the initial connection.
>>
>> The verdict according to "git bisect" is that  
>> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:
>>
>> Does that look like it might be the issue? Anyone familiar with  
>> that part of the code care to comment? Any other info I can provide  
>> that might shed light on the problem?
>
> Prior to that patch, execv_git_cmd called execve in a loop to find  
> the command to run. The above patch added a setup_path() api to  
> setup PATH and then called execvp() to do the looping. The problem  
> in this case is that daemon is never calling setup_path(), so the  
> builtin path (among others) aren't getting included in the PATH.
>
> You should see the problem go away if you run "git daemon" instead  
> of "git-daemon". Given that directly using the dash versions of the  
> commands are discouraged, it probably wouldn't hurt doing this  
> anyway. I'll work up a patch later today.

> I just noticed that my copy of git-daemon running from xinetd on Red
> Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.
>
> On the client side this is what you see ("git clone" used in the
> example but you get the same issue with "git ls-remote"):
>
>   git clone git://git.wincent.com/wikitext.git
>   Initialized empty Git repository in /tmp/wikitext/.git/
>   fatal: The remote end hung up unexpectedly
>   fetch-pack from 'git://git.wincent.com/wikitext.git' failed.
>
> Nothing printed to the logs on the server side: it simply hangs up. By
> connecting via telnet I've confirmed that git-daemon is running and
> does accept the initial connection.
>
> The verdict according to "git bisect" is that
> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:
>
> commit 511707d42b3b3e57d9623493092590546ffeae80
> Author: Scott R Parish <srp@srparish.net>
> Date:   Sun Oct 28 04:17:20 2007 -0700
>
>     use only the $PATH for exec'ing git commands

> Wincent Colaiuta <win@wincent.com> writes:
>
>> I just noticed that my copy of git-daemon running from xinetd on Red
>> Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.
>>
>> On the client side this is what you see ("git clone" used in the
>> example but you get the same issue with "git ls-remote"):
>>
>>  git clone git://git.wincent.com/wikitext.git
>>  Initialized empty Git repository in /tmp/wikitext/.git/
>>  fatal: The remote end hung up unexpectedly
>>  fetch-pack from 'git://git.wincent.com/wikitext.git' failed.
>>
>> Nothing printed to the logs on the server side: it simply hangs up.  
>> By
>> connecting via telnet I've confirmed that git-daemon is running and
>> does accept the initial connection.
>>
>> The verdict according to "git bisect" is that
>> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:
>>
>> commit 511707d42b3b3e57d9623493092590546ffeae80
>> Author: Scott R Parish <srp@srparish.net>
>> Date:   Sun Oct 28 04:17:20 2007 -0700
>>
>>    use only the $PATH for exec'ing git commands
>
> Perhaps you did not install git on the PATH processes launched
> by your inetd implementation would use?

> This fails with the "remote end hung up unexpectedly" error:
>
>    # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah
>
> Drop the --inetd option and it works with no errors:

> Wincent Colaiuta <win@wincent.com> writes:
>
>> This fails with the "remote end hung up unexpectedly" error:
>>
>>   # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah
>>
>> Drop the --inetd option and it works with no errors:
>
> Do you mean you run the above from your command line and it
> fails?

> El 5/2/2008, a las 21:02, Junio C Hamano escribió:
>> Perhaps you did not install git on the PATH processes launched
>> by your inetd implementation would use?
> 
> I don't know what PATH environment xinetd provides, but I can reproduce
> this directly as follows from the command line without any involvement
> from xientd:
> 
> First, set up PATH with all the standard locations, with directories
> under /usr/local specified first. Git 1.5.4 is installed in /usr/local/bin:
> 
>   # export
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
> 
> This fails with the "remote end hung up unexpectedly" error:
> 
>   # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah

>> This fails with the "remote end hung up unexpectedly" error:
>>
>>  # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah
>
> If you run this from the command line, you can't expect it to do  
> anything
> useful: It communicates with the client via stdin and stdout.

> Which makes me think that you xinetd doesn't pass a PATH to git-daemon
> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:
>
>    env = PATH=/bin:/usr/bin:/usr/local/bin
>
> (not tested).

> El 6/2/2008, a las 10:40, Johannes Sixt escribió:
> 
>>> This fails with the "remote end hung up unexpectedly" error:
>>>
>>>  # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah
>>
>> If you run this from the command line, you can't expect it to do anything
>> useful: It communicates with the client via stdin and stdout.
> 
> Strangely, it worked with 1.5.3.8. But I just tried to reproduce it and
> now I can't, so there must have been some error in my procedure. Doh.
> The bizarre thing is that in preparing these emails I tested it at least
> twice, which means I must have made the exact same mistake at least
> twice...
> 
>> Which makes me think that you xinetd doesn't pass a PATH to git-daemon
>> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:
>>
>>    env = PATH=/bin:/usr/bin:/usr/local/bin
>>
>> (not tested).
> 
> That works. Thanks.
> 
> It's an acceptable workaround (the other is installing /usr instead of
> /usr/local). Seeing as it worked in 1.5.3.8, does this qualify as
> breakage, or should we not worry about it?

>>> Which makes me think that you xinetd doesn't pass a PATH to git- 
>>> daemon
>>> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:
>>>
>>>   env = PATH=/bin:/usr/bin:/usr/local/bin
>>>
>>> (not tested).
>>
>> That works. Thanks.
>>
>> It's an acceptable workaround (the other is installing /usr instead  
>> of
>> /usr/local). Seeing as it worked in 1.5.3.8, does this qualify as
>> breakage, or should we not worry about it?
>
> Does this patch make a difference? (It does for me.)

> diff --git a/daemon.c b/daemon.c
> index 41a60af..c99285e 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1026,6 +1026,7 @@ int main(int argc, char **argv)
> 	struct group *group;
> 	gid_t gid = 0;
> 	int i;
> +	char *cmd_path = strdup(argv[0]), *slash;
>
> 	/* Without this we cannot rely on waitpid() to tell
> 	 * what happened to our children.
> @@ -1184,6 +1185,13 @@ int main(int argc, char **argv)
> 	if (strict_paths && (!ok_paths || !*ok_paths))
> 		die("option --strict-paths requires a whitelist");
>
> +	slash = strrchr(cmd_path, '/');
> +	if (slash) {
> +		*slash = 0;
> +		setup_path(cmd_path);
> +	}
> +	free(cmd_path);
> +
> 	if (inetd_mode) {
> 		struct sockaddr_storage ss;
> 		struct sockaddr *peer = (struct sockaddr *)&ss;

> Wincent Colaiuta schrieb:
>> Drop the --inetd option and it works with no errors:
>>
>>   # /usr/local/bin/git-daemon --base-path=/blah -- /blah
> 
> When I run git-daemon with a reduced path similar to this:
> 
>    PATH=/bin:/usr/bin /usr/local/bin/git-daemon ...
> 
> i.e. git is installed in /usr/local/bin, but it is not in PATH, then I
> also get "hung up unexpectedly" from a client that connects to this server.
> 
> Which makes me think that you xinetd doesn't pass a PATH to git-daemon
> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:
> 
>     env = PATH=/bin:/usr/bin:/usr/local/bin
> 
> (not tested).

> When I run git-daemon with a reduced path similar to this:
> 
>    PATH=/bin:/usr/bin /usr/local/bin/git-daemon ...
> 
> i.e. git is installed in /usr/local/bin, but it is not in PATH, then I
> also get "hung up unexpectedly" from a client that connects to this server.
> 
> Which makes me think that you xinetd doesn't pass a PATH to git-daemon
> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:
> 
>     env = PATH=/bin:/usr/bin:/usr/local/bin