From: Jeff King <peff@peff.net>
Date: Tue, 25 Apr 2017 02:56:35 GMT
Subject: Re: [PATCH v6 12/11] run-command: don't try to execute directories
Message-ID: <20170425025634.q3n3umu3trhycigm@sigill.intra.peff.net>
In-Reply-To: <20170425001724.GG28740@aiede.svl.corp.google.com>

On Mon, Apr 24, 2017 at 05:17:24PM -0700, Jonathan Nieder wrote:

> > This is due to only checking 'access()' when locating an executable in
> > PATH, which doesn't distinguish between files and directories.  Instead
> > use 'stat()' and check that the path is to a regular file.  Now
> > run-command won't try to execute the directory 'git-remote-blah':
> >
> > 	$ git ls-remote blah://blah
> > 	fatal: Unable to find remote helper for 'blah'
> >
> > Signed-off-by: Brandon Williams <bmwill@google.com>
> 
> For the interested, the context in which this was reported was trying
> to execute a directory named 'ssh'.  Thanks for a quick fix.
> 
> Technically this bug has existed since
> 
> 	commit 38f865c27d1f2560afb48efd2b7b105c1278c4b5
> 	Author: Jeff King <peff@peff.net>
> 	Date:   Fri Mar 30 03:52:18 2012 -0400
> 
> 	   run-command: treat inaccessible directories as ENOENT
> 
> Until we switched from using execvp to execve, the symptom was very
> subtle: it only affected the error message when a program could not be
> found, instead of affecting functionality more substantially.

Yeah, I'm pretty sure I didn't think at all about access() matching
directories when doing that commit. Using stat() does seem like the
right solution.

-Peff