a service not in PATH fails to execute

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run shellinaboxd with a service argument that points at a binary not in 
$PATH (as seen from shellinaboxd). E.g.: -s 
/:shellinabox:shellinabox:/:/usr/local/scripts/sb-ssh-wrapper ${url}
2. Connect to the running shellinaboxd instance from a browser to initiate 
a new session.

What is the expected output? What do you see instead?
Expected: The session starts successfully and the browser displays the 
output of the above script.

What happens: shellinaboxd strips the path information from the service 
definition and uses execvp() to find the service in $PATH. Since 
/usr/local/scripts is not in $PATH, it fails to find sb-ssh-wrapper and 
fails. All I get is "Session closed" in the web browser.

This behavior is at the very end of the execService() function in 
shellinabox/launcher.c. I confirmed it by strace'ing shellinaboxd:

[pid  7029] chdir("/")                  = 0
[pid  7029] execve("/usr/local/bin/sb-ssh-wrapper", 
["/usr/local/scripts/sb-ssh-wrappe"..., "https://realify.com/ssh/gary/"], 
[/* 8 vars */]) = -1 ENOENT (No such file or directory)
[pid  7029] execve("/usr/bin/sb-ssh-wrapper", ["/usr/local/scripts/sb-ssh-
wrappe"..., "https://realify.com/ssh/gary/"], [/* 8 vars */]) = -1 ENOENT 
(No such file or directory)
[pid  7029] execve("/bin/sb-ssh-wrapper", ["/usr/local/scripts/sb-ssh-
wrappe"..., "https://realify.com/ssh/gary/"], [/* 8 vars */]) = -1 ENOENT 
(No such file or directory)
[pid  7029] execve("/usr/games/sb-ssh-wrapper", ["/usr/local/scripts/sb-
ssh-wrappe"..., "https://realify.com/ssh/gary/"], [/* 8 vars */]) = -1 
ENOENT (No such file or directory)
[pid  7029] exit_group(1)               = ?

execService() needs to not strip path information from the first argument 
to execvp().

Moving sb-ssh-wrapper to /usr/local/bin (which is in $PATH) made the 
problem go away.

What version of the product are you using? On what operating system?
Version: 2.10-1
OS: Debian Lenny (5.0.4)
shellinabox is compiled from source using the Debian package definition in 
the source tarball.

Original issue reported on code.google.com by happily....@gmail.com on 18 Feb 2010 at 11:19

[GoogleCodeExporter]

I can confirm the same behaviour on CentOs 6.2.

Original comment by d250labo...@gmail.com on 28 Feb 2012 at 1:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Very confusing, never would have realised this was my problem if this bug 
wasn't filed, thanks :)

Original comment by jer...@nickurak.ca on 3 Oct 2013 at 5:00