Re: [PATCH] run-command: don't try to execute directories

Junio C Hamano [off-list ref] writes:

Carlos Martín Nieto [off-list ref] writes:

quoted

When looking through $PATH to try to find an external command,
locate_in_PATH doesn't check that it's trying to execute a file. Add a
check to make sure we won't try to execute a directory.

This also stops us from looking further and maybe finding that the
user meant an alias, as in the case where the user has
/home/user/bin/git-foo/git-foo.pl and an alias

    [alias] foo = !/home/user/bin/git-foo/git-foo.pl

Running 'git foo' will currently will try to execute ~/bin/git-foo and
fail because you can't execute a directory. By making sure we don't do
that, we realise that it's an alias and do the right thing

Signed-off-by: Carlos Martín Nieto <redacted>

---

This comes from a case in #git. Not sure if this is worth it, or the
better solution is just to say no to dirs in $PATH.

After writing all of that, I thought to check the shell, and indeed

    % git-foo
    zsh: permission denied: git-foo

so if the shell doesn't do it, the benefits probably don't outweigh
having a dozen stat instead of access calls. strace reveals that zsh
does what git currently does. bash uses stat and says 'command not
found'.

Hrm, I do not use zsh but it does not seem to reproduce for me.

	$ mkdir -p /var/tmp/xx/git
        $ zsh
        % PATH=/var/tmp/xx:$PATH
        % type git
        git is /home/junio/bin/git
        % git version
        git version 1.8.0.rc0.45.g7ce8dc5
	% zsh --version
	zsh 4.3.10 (x86_64-unknown-linux-gnu)

zsh has some quite aggressive PATH caching. I did this with git-foo in
the path so it didn't already know what to look for. I can reproduce
what you saw, but also consider this:

    % /var/tmp/xx/git
    zsh: permission denied: /var/tmp/xx/git
    % zsh --version
    zsh 4.3.17 (x86_64-unknown-linux-gnu)

If you change your test to use git-foo instead of just git, you should
see what I wrote in the message.

bash rightfully complains that it's a stupid thing to do.

    $ /var/tmp/xx/git
    bash: /var/tmp/xx/git: Is a directory

quoted

@@ -101,8 +102,9 @@ static char *locate_in_PATH(const char *file)
 		}
 		strbuf_addstr(&buf, file);
 
-		if (!access(buf.buf, F_OK))
+		if (!stat(buf.buf, &st) && !S_ISDIR(st.st_mode)) {
 			return strbuf_detach(&buf, NULL);
+		}

So we used to say "if it exists and accessible, return that".  Now
we say "if it exists and is not a directory, return that".

I have to wonder what would happen if it exists as a non-directory
but we cannot access it.  Is that a regression?

I guess it would be, yeah. Would this be related to tha situation where
the user isn't allowed to access something in their PATH?

How about something like this instead? We keep the access check and only
do the stat call when we have found something we want to look at.

   cmn

---8<---

diff --git a/run-command.c b/run-command.c
index 1101ef7..fb8a93c 100644
--- a/run-command.c
+++ b/run-command.c

@@ -85,6 +85,7 @@ static char *locate_in_PATH(const char *file)
 {
        const char *p = getenv("PATH");
        struct strbuf buf = STRBUF_INIT;
+       struct stat st;
 
        if (!p || !*p)
                return NULL;

@@ -101,7 +102,8 @@ static char *locate_in_PATH(const char *file)
                }
                strbuf_addstr(&buf, file);
 
-               if (!access(buf.buf, F_OK))
+               if (!access(buf.buf, F_OK) &&
+                   !stat(buf.buf, &st) && !S_ISDIR(st.st_mode))
                        return strbuf_detach(&buf, NULL);
 
                if (!*end)

On Tue, Oct 02, 2012 at 09:32:11PM +0200, Carlos Martín Nieto wrote:

quoted

quoted

@@ -101,8 +102,9 @@ static char *locate_in_PATH(const char *file)
 		}
 		strbuf_addstr(&buf, file);
 
-		if (!access(buf.buf, F_OK))
+		if (!stat(buf.buf, &st) && !S_ISDIR(st.st_mode)) {
 			return strbuf_detach(&buf, NULL);
+		}

So we used to say "if it exists and accessible, return that".  Now
we say "if it exists and is not a directory, return that".

I have to wonder what would happen if it exists as a non-directory
but we cannot access it.  Is that a regression?

I guess it would be, yeah. Would this be related to tha situation where
the user isn't allowed to access something in their PATH?

This code path is related to correcting EACCES errors into ENOENT. But
it does not bother checking permissions itself.  We know there is some
permission problem, because execvp told us EACCES, so we are only
checking whether such a file actually exists at all in the PATH. And
that is why we are using F_OK with access, and not X_OK.

So any reason for which stat() would fail would presumably cause
access(F_OK) to fail, too (mostly things like leading directories not
being readable), and I think converting the access into a stat is OK.

Adding the !ISDIR on top of it makes sense if you want to consider the
directory in your PATH to be a harmless thing to be ignored. However, I
am not sure that is a good idea. The intent of ignoring the original
EACCES is that it could be caused by totally uninteresting crap, like an
inaccessible directory in your PATH.

Whereas in this case, the error really is that we found "git-foo", but
it is somehow broken. And it almost certainly is a configuration error
on the part of the user (why would they put a git-foo directory in their
PATH? Presumably they meant to put its contents into the PATH).

So I think your implementation is fine, but I'm a little dubious of the
value of ignoring such an error.

-Peff