Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Feb 2020 09:27:43 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: execvp() behaviour with unrecognized file header

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

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.