Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.unix.shell
Subject: Re: Default PATH setting - reduce to something more sensible?
Date: Sun, 26 Jan 2025 05:26:38 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <20250125211146.219@kylheku.com>
References: <vm5dei$2c7to$1@dont-email.me>
 <vmthmu$3bb88$1@news.xmission.com> <vmtrqk$92b$1@reader2.panix.com>
 <vmu94j$1q2lp$1@dont-email.me> <vn05ji$r20$1@reader2.panix.com>
 <vn0bpf$29qe6$1@dont-email.me> <871pwr6fe9.fsf@nosuchdomain.example.com>
 <vn2ier$2phv1$1@dont-email.me> <87ed0qba54.fsf@nosuchdomain.example.com>
Injection-Date: Sun, 26 Jan 2025 06:26:39 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0b769d247bac7540b375d3c3eb5311fe";
	logging-data="3637750"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/NBrWpBEttzrIxyH8CkyemTUOz3K/6BS8="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:z/y4mz5fZA3aNlx5urkD8US2ldw=
Bytes: 3964

On 2025-01-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 24.01.2025 23:00, Keith Thompson wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 24.01.2025 14:46, Dan Cross wrote:
>>> [...]
>>> 
>>> /usr/bin/which is limited in what it can do.  It follows POSIX-specified
>>> behavior for $PATH; it doesn't recognize any shell-specific rules. [...]
>>
>> Sure.
>>
>>> [...]
>>>> The settings  PATH=~/bin  and  PATH="~/bin"  respectively shall
>>>> result in the same behavior across shells when searching for
>>>> programs; in the first case looking into "/home/someuser/bin/"
>>>> and in the second case looking into "./~/bin/" (i.e. a path
>>>> component with a local directory named "~").
>>> 
>>> What do you mean by "shall result?
>>
>> I mean that a shell should behave consistently. (I think Bash does
>> not in the given case.)
>
> Consistently with what?  Bash consistently expands literal '~'s in
> $PATH, and consistently disables that expansion in POSIX mode.
>
> All shells have shell-specific features.  What's odd about this case is
> that bash has a POSIX-violating feature that affects command name
> resolution.

It's a feature that (if used) leaks tildes into child processes via
the environment variable. Path resultion in child processes, if it
reaches a PATH element with a tilde, will somehow process that tilde.

I just tried this experiment. I made a directory named ~ and put ~:
as the leading element of PATH. I put a program called "foo" that
directory.

Surely enough, I can run "foo" from the parent directory above.

The exec functions treat ~ as an ordinary path component.

(I cannot do that out of Bash, which processes the tilde, but
the 'p' family of the exec functions will find it!)

This is a problem similar to "." being in PATH.

If someone has, say, "~/bin" in their PATH, ahead of /bin and /usr/bin,
I can put a malicious program in some directory called "~/bin"
somewhere in the filesystem, give that program the name of a common
external utility, and trick the user into changing into that location
where they will run this common command, resolving to my malicious
program.

If we regard this as a security hole, that atually raises the priority
and bolsters the argument that it ought to be removed even if it
breaks some users, perhaps through a process of noisy deprecation.

Furhermore, the case can be made that the exec stuff in the Linux kernel
or C libraries should be patched with a check against components with a
leading tilde.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca