[PATCH] posix: execvpe: skip $PATH components that are too long

[Zack Weinberg]

On Tue, Nov 18, 2025, at 8:27 AM, Pádraig Brady wrote:
> Bruno Haible wrote:
>  > Paul Eggert wrote:
>  > > The situation for ENAMETOOLONG is the same.
>  >
>  > Well, in [1] I'm arguing that the situation for ENAMETOOLONG is
>  > _not_ the same. If one ignores ENAMETOOLONG errors from earlier PATH
>  > elements, a user's intent to hide (override) a certain program from
>  > later PATH elements is no longer honored.
>
>  > One could consider this as security relevant. CCing Florian.
>
> In summary I don't think we should be treating ENAMETOOLONG
> differently to how we treat EACCES or ENOTDIR.
> If we can't access file through a path, then we should try the next one.
>
> There are a few cases to consider:
>
> 1. /many/path/file > PATH_MAX
> 2. /path/longpath/file > NAME_MAX
> 3. /path/longfile > NAME_MAX

I think the appropriate distinction is a little different:  I think it
should be about whether the _directory_ or a _specific file_ is the problem.
Concretely, suppose 

   PATH = /very/long/path : /bin

(spaces for readability only)

If stat("/very/long/path") returns ENAMETOOLONG, i.e. _nothing_ in
that directory can be accessed without hitting a length limit, then
I do think we ought to skip that directory and go on to the next one.
Otherwise, you could lock yourself out of all commands other than
shell builtins by prepending an overlength directory to your PATH,
and that could be a very confusing situation to be stuck in.

However, if stat("/very/long/path") succeeds but
execve("/very/long/path/someprogram") returns ENAMETOOLONG, then
I think Bruno is right and we should stop searching and return the
error.  Again, for me this is about ease of troubleshooting.  If you
_know_ you put a program with an unusually long name in your personal
$HOME/.local/bin and you _know_ other programs under that directory
do get used in preference to the system's, then having the program
with the long name get silently ignored would also be very confusing.

This distinction is also consistent with how we currently handle
ENOTDIR and EACCES errors.  ENOTDIR from execve indicates a problem
with a directory on the PATH - namely, that it isn't a directory -
not with the specific program that's trying to be executed, so we
skip it and go on to the next one.  EACCES errors are reported when
the program file that can't be accessed, whether or not there's a
usable program by the same name later in the PATH; but not when an
entire directory is inaccessible.

zw