From: Jeff King <peff@peff.net>
To: James Pickens <jepicken@gmail.com>
Cc: Git ML <git@vger.kernel.org>
Subject: Re: Bug? Bad permissions in $PATH breaks Git aliases
Date: Mon, 26 Mar 2012 23:19:53 -0400 [thread overview]
Message-ID: <20120327031953.GA17338@sigill.intra.peff.net> (raw)
In-Reply-To: <CAJMEqRBmuBJuUmeoAU-_xf=s10ybD9pXhUJT+fn8aHNE2WJz6A@mail.gmail.com>
On Mon, Mar 26, 2012 at 04:48:29PM -0700, James Pickens wrote:
> I'm not sure if this should be considered a bug or not, but I've noticed that
> when my $PATH contains an inaccessible directory, Git fails to execute aliases.
> For example:
>
> git config alias.l log
> git l
> # works fine
> PATH=boguspath:$PATH
> mkdir boguspath
> chmod 000 boguspath
> git l
> # fatal: cannot exec 'git-l': Permission denied
This seems to come up about once a year. The short of it is that execve
will return EACCESS whether the file exists is not actually executable
by you, or if you have an inaccessible element in your PATH. execvp will
continue the search if it sees EACCESS, but will return EACCESS if it
finds nothing. So git just sees the EACCESS and doesn't know if you
have bogus entries in your PATH or if there is a permissions problem
with your executable files.
For something like a shell, it's not that big a deal; either way, you
couldn't execute the command in question. For git, it matters more
because we first try to exec an external command, and then fall back to
an alias (because externals take precedence over aliases).
So basically our options are:
1. Start treating EACCESS silently as ENOENT. The downside is that we
fail to report the proper error when the file really does have
permissions problems (we would say "command not found", but that is
misleading).
2. Implement our own execvp, differentiating between "path not
available for looking in" and "we found the command, but there was
a permissions problem". I think somebody was working on this a few
months ago (search for "add exeecvp failure diagnostics") but it
seems to have fizzled.
3. If we get an EACCESS, remember it, try to do the alias lookup, and
then if that fails, report the "Permission denied" error (not
"command not found"). That is following the spirit of what execvp
does (it will find later entries in the PATH if they are there, but
otherwise will remember the EACCESS error).
>From what I can tell, dash uses stock execvp, and ends up closest to
(3). Bash seems to have implemented their own path lookup, as it will
distinguish between the two cases as in (2):
$ mkdir /tmp/foo
$ chmod 0 /tmp/foo
$ PATH=/tmp/foo:$PATH
$ dash -c does-not-exist
dash: 1: does-not-exist: Permission denied
$ bash -c does-not-exist
bash: does-not-exist: command not found
$ chmod 755 /tmp/foo
$ >/tmp/foo/does-not-exist
$ chmod 0 /tmp/foo/does-not-exist
$ dash -c does-not-exist
dash: 1: does-not-exist: Permission denied
$ bash -c does-not-exist
bash: /tmp/foo/does-not-exist: Permission denied
I think the general feeling last time this came up was "why not just
remove the cruft from your PATH?" But I would personally be OK with
option (3) above, and it is probably not that hard to implement.
-Peff
next prev parent reply other threads:[~2012-03-27 3:20 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-26 23:48 Bug? Bad permissions in $PATH breaks Git aliases James Pickens
2012-03-27 3:19 ` Jeff King [this message]
2012-03-27 7:25 ` James Pickens
2012-03-27 15:11 ` Junio C Hamano
2012-03-27 17:59 ` Jeff King
2012-03-27 18:04 ` [PATCH 1/2] run-command: propagate EACCES errors to parent Jeff King
2012-03-27 18:24 ` Junio C Hamano
2012-03-27 18:33 ` Jeff King
2012-03-27 18:05 ` [PATCH 2/2] git: continue alias lookup on EACCES errors Jeff King
2012-03-27 19:16 ` Junio C Hamano
2012-03-28 4:30 ` Jeff King
2012-03-28 17:42 ` Junio C Hamano
2012-03-28 17:48 ` Jeff King
2012-03-28 18:04 ` Jonathan Nieder
2012-03-28 18:31 ` Junio C Hamano
2012-03-28 18:40 ` Jonathan Nieder
2012-03-28 19:39 ` Jeff King
2012-03-28 19:45 ` Jonathan Nieder
2012-03-28 20:18 ` Jeff King
2012-03-28 20:37 ` Jeff King
2012-03-28 20:51 ` Jonathan Nieder
2012-03-28 20:52 ` Jeff King
2012-03-28 20:42 ` Jonathan Nieder
2012-03-28 20:51 ` Jeff King
2012-03-28 21:01 ` Jonathan Nieder
2012-03-28 21:25 ` Jeff King
2012-03-28 21:30 ` Frans Klaver
2012-03-28 20:43 ` Junio C Hamano
2012-03-28 21:04 ` Jeff King
2012-03-28 21:44 ` Junio C Hamano
2012-03-28 21:57 ` Jeff King
2012-03-28 22:07 ` Jeff King
2012-03-28 22:18 ` Junio C Hamano
2012-03-29 11:31 ` Frans Klaver
2012-03-29 17:20 ` Jeff King
2012-03-29 17:23 ` Frans Klaver
2012-03-28 19:38 ` Jeff King
2012-03-28 18:29 ` Junio C Hamano
2012-03-28 19:40 ` Jeff King
2012-03-29 11:16 ` Frans Klaver
2012-03-29 17:15 ` Jeff King
2012-03-29 17:21 ` Frans Klaver
2012-03-27 6:14 ` Bug? Bad permissions in $PATH breaks Git aliases Johannes Sixt
2012-03-27 7:37 ` James Pickens
2012-03-27 15:14 ` Junio C Hamano
2012-03-27 17:48 ` James Pickens
2012-03-27 18:03 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120327031953.GA17338@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jepicken@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).