Re: Default PATH setting - reduce to something more sensible?

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