[PATCH] execlp, execvp, execvpe: Don't fall back to sh on ENOEXEC.

[Adhemerval Zanella]

On 15/12/2020 13:05, Zack Weinberg wrote:
> When direct execution of a program fails with ENOEXEC, do not attempt
> to run that program as if it were a shell script.  The change affects
> execlp, execvp, execvpe, and the compatibility versions of posix_spawn
> and posix_spawnp (symbol version GLIBC_2_2).  There is no provision
> for backward binary compatibility, as I consider the old behavior to
> be a bug.  It was inconsistent with the behavior of the rest of the
> exec* family of functions, it could cause severe malfunctions of
> correct-looking code, and I can even put together a (relatively
> far-fetched) scenario where it opens a security hole.
> 
> The internal function __execvpex is no longer necessary and is
> removed, as is the internal flag SPAWN_XFLAGS_TRY_SHELL.  Tests
> posix/tst-{execvp3,execvpe3,spawn4-compat}.c were testing this
> misfeature and are removed entirely.  Tests execvpe6.c and vfork3.c
> are modified not to rely on the misfeature.
> 
> This is an intentional deviation from POSIX, anticipating the change
> requested in Austin Group bug #1435.  Austin currently doesn't seem
> enthusiastic about the idea.  I think we should make this change *even
> if* they reject it.

Although I tend to agree with the rationale, I think we should follow
current practice of moving legacy semantics to compat symbols, evaluate
the usage by releasing some version with the change, and then check 
if would make sense to also change the compat symbols.

So I would suggest to on 2.33 add new versions for execlp, execvp, execvpe
without the ENOEXEC support, and move the current semantic to compat
support. 

We can then even add the security mitigations suggested by Paul on compat
symbols without the drawbacks raised by you, at least on newer programs
linked to the newer symbols.