From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 726F13858D28; Mon, 31 Jul 2023 19:13:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 726F13858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1690830782; bh=ErTINuyjrxPpfEFHaqJ1HMVMnrNW127x8HRje+yR4Oo=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=e29u6UcW/RltIHJl17bDXGH5U491XNg6FhEpLw8lZwCCpeQAPE5TbYnKFbtrrPhus 7kPt0UgGpQGYNG2NopmGQ0ZzGE4vGU6TstHowVLz+s9CLT9M7zWK8QMFjcdJT1u2hs Rn7JPgrZ8dtFPpW3Tl59cScOcz/bIglSm5d0ep58= Received: by calimero.vinschen.de (Postfix, from userid 500) id C9B14A807B2; Mon, 31 Jul 2023 21:12:59 +0200 (CEST) Date: Mon, 31 Jul 2023 21:12:59 +0200 From: Corinna Vinschen To: Eric Blake Cc: Bruno Haible , cygwin@cygwin.com Subject: Re: posix_spawn facility Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: Eric Blake , Bruno Haible , cygwin@cygwin.com References: <1752276.7aRn1RRit1@nimes> <5022555.upeRZZJTqa@nimes> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Hi Eric, On Jul 31 13:58, Eric Blake via Cygwin wrote: > Following up on an older thread: > > On Tue, Apr 18, 2023 at 03:49:20PM -0500, Eric Blake wrote: > > The glibc bug points to the sample posix_spawn() implementation in > > POSIX XRAT - but that example implementation is non-normative and > > known buggy, so it is not safe to rely on it. > > > > Clarifying the wording in XRAT to explicitly mention that the example > > is NOT bullet-proof (and that implementations should do better) is > > probably worthwhile; I'll tackle that bug report. > > > > > > > > Second, the rational section in POSIX explains posix_spawn and > > > posix_spawnp, but it does *not* actually provide an example > > > implementation of posix_spawnp, only of posix_spawn. > > > > POSIX is silent as to whether posix_spawnp() has to fall back to 'sh' > > on ENOEXEC failure. The p suffix is indeed similar to execvp() (which > > DOES require a fallback to sh), but it could also just mean a > > PATH-search, and not the PATH-search-and-sh-fallback of execvp(). As > > we now have implementations in the wild that differ in behavior, and > > use security as a reason for the divergence, it is worth getting that > > clarified in POSIX. I'll file a bug against POSIX shortly, and reply > > again once it is up. > > > > My personal preference: sh fallback on ENOEXEC is useful in execvp(), > > but a bear to get right (see > > https://www.austingroupbugs.net/view.php?id=1645 where POSIX has a bug > > in requiring argv[0] to be the script's filename, which breaks busybox > > sh and is NOT what glibc does; meanwhile, musl intentionally does NOT > > do the sh fallback), so NOT doing it in posix_spawnp() would be > > reasonable; but we'll have to see what the rest of the Austin Group > > says. > > ... > > > > > Yeah, it appears that POSIX is (accidentally) silent on whether > > posix_spawnp() has to do the sh fallback on ENOEXEC; but it seems > > quite reasonable that posix_spawn() being more like execle() must NOT > > do a sh fallback. > > The Austin Group finally visited the topic today; result is that in > the next version of POSIX, it will be explicit that neither > posix_spawn() nor posix_spawnp() are allowed to attempt sh fallback > (instead, they must fail with ENOEXEC if detected in the parent, or > with status 127 if after creating the child). > > https://austingroupbugs.net/view.php?id=1674#c6411 Ok, clear words. Fortunately I already pushed that patch a while ago: https://cygwin.com/cgit/newlib-cygwin/commit/?id=da40bd6eaf40 Thanks for keeping us in the loop! Corinna