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

[Collin Funk]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:

> On 18/11/25 10:27, 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
>> 
>> 3. is already handled by glibc's execvpe, so let's just consider 1. and 2.
>> 
>> It's also worth noting that these limits can vary based on the file system.
>> For example we've seen NAME_MAX = 143 on ecryptfs as it uses some of the
>> file name space for encrypting file names.
>> 
>> With 2. the path can't exist on the (file) system,
>> so you'd want to treat that like ENOTDIR IMHO.
>> 
>> With 1. the /many/path/file might exist, but since it's not accessible
>> you'd want to treat that like EACCES IMHO.
>> This case is also more of an edge case I think.
>> 
>> The use case of a user wanting ENAMETOOLONG to abort $PATH processing would be unusual.
>> If they have access to changing $PATH then the natural way to achieve that functionality
>> would be to remove entries they want avoided.
>> 
>> Given the fairly constrained NAME_MAX in some cases (like on ecryptfs),
>> I think it's more expected to continue processing paths
>> when encountering ENAMETOOLONG.
>> 
>
> I think it makes sense to handle ENAMETOOLONG as ENOENT, ESTALE, ENOTDIR,
> ENODEV, and ETIMEDOUT.  It is consistency with the systems (BSDs) and how
> other executors already handle it (shells).

I don't have a strong opinion on the change, but making it match BSD
makes sense.

However, we should probably save this for after the release, correct?

Collin