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

[Pádraig Brady]

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.

thanks,
Padraig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-glibc-execvpe-enametoolong.patch
Type: text/x-patch
Size: 3839 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251118/72a89ced/attachment.bin>