From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Priedhorsky, Reid" <reidpr@lanl.gov>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: bug? subprocesses can use wrong Git if $PATH is unset
Date: Fri, 2 Jun 2023 00:35:35 +0000 [thread overview]
Message-ID: <ZHk5V6U9gfkuwErH@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <E7D87B07-C416-4A58-8726-CCDA0907AC66@lanl.gov>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
On 2023-06-01 at 22:21:05, Priedhorsky, Reid wrote:
> Hello,
>
> I may have found a bug in Git. It seems that if (1) multiple git(1) are installed on the system, (2) one is in the shell’s default path (i.e., used if $PATH is unset, not the default value of $PATH), and (3) the desired git(1) is at a different path, then subprocesses of the desired git(1) invoke the undesired git(1) instead.
>
> $PATH unset is indeed a pathological situation; one of our own bugs in our software that calls git(1) inappropriately cleared it. However, in my view it’s surprising enough to be a usability bug. I would expect git(1) to call itself for subprocesses regardless of the environment.
I don't believe this is a bug in Git, but rather a behaviour of your
operating system kernel. If you don't set PATH, then when Git does an
exec, the kernel or libc supplies a default PATH value. Traditionally
this includes /bin and /usr/bin, and on some systems, it used to contain
the current working directory, which has typically been removed for
security.
It isn't possibly to portably determine that path that was used to exec
the current binary, so Git doesn't try to do so, and it assumes that you
set PATH appropriately. In fact, on some systems, you can use fexecve
to execute file descriptors pointing to files that have been unlinked,
so in general, it's not possible to determine which binary to use
without the PATH.
I'm not aware of any other major programs which do this in a better or
more useful way, so I don't think there's anything to change here in
Git.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2023-06-02 0:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 22:21 bug? subprocesses can use wrong Git if $PATH is unset Priedhorsky, Reid
2023-06-02 0:35 ` brian m. carlson [this message]
2023-06-02 16:14 ` Priedhorsky, Reid
2023-06-02 20:20 ` brian m. carlson
2023-06-03 1:38 ` Junio C Hamano
2023-06-07 17:43 ` Priedhorsky, Reid
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=ZHk5V6U9gfkuwErH@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=reidpr@lanl.gov \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).