execvpe limits PATH environment variable to PATH_MAX

[Adhemerval Zanella]

On 30/03/2020 13:57, Nils Andre wrote:
> Hello,
> 
> Commit 1eb8930608705702d5746e5491bab4e4429fcb83, limits the length of
> the `PATH` environment variable to `PATH_MAX`. The commit message just
> mentions it without explaining why that is the case.
> 
> Considering that using `nix-shell`[1], to load a [ccextractor][2] development
> environment, my `PATH` ends up being 2033 bytes long, I find the limit
> to `PATH_MAX` quite tight and arbitrary.
> 
> Regardless of the whether the limit is narrow or not, I find that
> setting a hard limit for `PATH` to be unintuitive as there is no reason
> to assume that `PATH` will fall under a certain limit. Even more so,
> when using `PATH_MAX` (as the limit) because it is unrelated.
> 
> Would it be possible to know the reason for this limit?
> 
> Thank you,
> 
> Nils ANDRÉ-CHANG
> 
> [1]: https://nixos.org/nix/manual/#sec-nix-shell
> [2]: https://github.com/CCExtractor/ccextractor
> 

The change was to make it semantically similar to execl and execle
where POSIX requires to be async-signal-safe.  It also fixes an
possible issue when used internally by posix_spawn, since the
helper process that eventually spawns the new process is created
with CLONE_VM.

And I don't think it would be a good practice to use a different
semantic for execvpe, i.e, allow arbitrary size paths.  It would 
require either dynamic allocation or an unbounded static
allocation (such some systems do, for instance FreeBSD). 

Former is hard to make async-signal-safe (glibc only supports on
single-thread case) and latter might be exploited as a security
issue and it would also make hard to support posix_spawn (since
we create an alternate stack with limited size for the helper
process).

I think it should be feasible to make execpve async-signal-safe
by using mmap (although POSIX itself does not state that mmap
is async-signal-safe) as least on Linux.