]> git.ipfire.org Git - thirdparty/git.git/commit - run-command.c
run-command: restrict PATH search to executable files
authorBrandon Williams <bmwill@google.com>
Tue, 25 Apr 2017 23:47:00 +0000 (16:47 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 26 Apr 2017 06:17:36 +0000 (23:17 -0700)
commit940283101ce87250cf31a592730386f5061e1286
tree8959b34793de45f243d177cbec99ad2c3a4df7a4
parent38124a40e480c1717326b7bc27bcbca758de908e
run-command: restrict PATH search to executable files

In some situations run-command will incorrectly try (and fail) to
execute a directory instead of an executable file.  This was observed by
having a directory called "ssh" in $PATH before the real ssh and trying
to use ssh protoccol, reslting in the following:

$ git ls-remote ssh://url
fatal: cannot exec 'ssh': Permission denied

It ends up being worse and run-command will even try to execute a
non-executable file if it preceeds the executable version of a file on
the PATH.  For example, if PATH=~/bin1:~/bin2:~/bin3 and there exists a
directory 'git-hello' in 'bin1', a non-executable file 'git-hello' in
bin2 and an executable file 'git-hello' (which prints "Hello World!") in
bin3 the following will occur:

$ git hello
fatal: cannot exec 'git-hello': Permission denied

This is due to only checking 'access()' when locating an executable in
PATH, which doesn't distinguish between files and directories.  Instead
use 'is_executable()' which check that the path is to a regular,
executable file.  Now run-command won't try to execute the directory or
non-executable file 'git-hello':

$ git hello
Hello World!

which matches what execvp(3) would have done when asked to execute
git-hello with such a $PATH.

Reported-by: Brian Hatfield <bhatfield@google.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command.c
t/t0061-run-command.sh