Re: [musl] execvp() behaviour with unrecognized file header

[Rich Felker <dalias@libc.org>]

On Wed, Feb 12, 2020 at 08:13:12AM -0600, A. Wilcox wrote:
> On 12/02/2020 07:54, Alexander Scherbatiy wrote:
> > Hello,
> > 
> > execvp() works differently on Linux Alpine and Ubuntu if it is called
> > with a file which does not contain a proper shebang line. The file is
> > executed on Ubuntu. It results to  ENOEXEC error on Linux Alpine.
> > 
> > man execvp on Ubuntu has description: "If the header of a file isn't
> > recognized (the attempted execve(2) failed with the error ENOEXEC),
> > these functions will execute the shell (/bin/sh) with the path of the
> > file as its first argument."
> > 
> > Does execvp() from musl behaves differently by purpose in this case?
> 
> 
> This has been discussed before on this list:
> 
> https://www.openwall.com/lists/musl/2018/03/09/1
> 
> Since this is non-conformant to POSIX, Adélie integrated quinq's patch:
> https://code.foxkit.us/adelie/musl/commit/16cbbea8e97d08e0fc6e9ccda0cf8b6e87ed6b82

Note that this patch has multiple problems which is why it's not
upstream: unbounded vla, inconsistency of not supporting the shell
behavior in execvpe (nonstandard extension, but should behave
analogously), and redundant code in execlp (execvp, which it's
calling, is already doing the fallback). I'm not sure what the right
fix is. These functions are supposed to be safe to use from a vforked
child, so allocation is kinda out of the question, at least not
without some heavy machinery to prevent a leak in the parent's address
space. I'd welcome ideas for a real fix.

Rich