From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 54691077 for ; Wed, 12 Feb 2020 14:27:57 +0000 (UTC) Received: (qmail 3309 invoked by uid 550); 12 Feb 2020 14:27:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3291 invoked from network); 12 Feb 2020 14:27:55 -0000 Date: Wed, 12 Feb 2020 09:27:43 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200212142743.GY1663@brightrain.aerifal.cx> References: <6ead5f7b-d645-5df0-cb06-a99178471a96@bell-sw.com> <1286e416-808c-9795-f76d-d8efa7c0125f@adelielinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1286e416-808c-9795-f76d-d8efa7c0125f@adelielinux.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] 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