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

On 26.01.2025 06:26, Kaz Kylheku wrote:

 
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.

[ Above context preserved for integrity. ]

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.

To my best knowledge using '/' as part of a file or directory name is
(as the '\0') prohibited by the operating system at a very low level.
So there would, IMO, not be a security hole (i.e. not because of that).

 
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.

Janis