X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C206385828D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1690830816;
	bh=ii7uohkdMwajdCNfakZucnH5g9Z7dmFx4yvdsFFGsB8=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=Xe4sN/WEmBlsu7Klde78dghUQrHcxwnx3+q1+ClejvBEPggtLxh2koN9/CKl6/6Cp
	 4KULdESZy+viVfxZyocFs242dCa9PIdLMm8/p2bYqtL1ICWWTvqaf3oHjXHVEPebbk
	 7o7OH2yRSk44kRH4oD6hHShZtU7AezuNpeXTBoHY=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 726F13858D28
Date: Mon, 31 Jul 2023 21:12:59 +0200
To: Eric Blake <eblake AT redhat DOT com>
Subject: Re: posix_spawn facility
Message-ID: <ZMgHu532JepRJZS5@calimero.vinschen.de>
Mail-Followup-To: Eric Blake <eblake AT redhat DOT com>,
 Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com
References: <1752276 DOT 7aRn1RRit1 AT nimes> <ZD0O442kk5d7VKrx AT calimero DOT vinschen DOT de>
 <5022555 DOT upeRZZJTqa AT nimes> <ZD5h973pS0tVenD0 AT calimero DOT vinschen DOT de>
 <xsn3qmrcprucviwtwoehm5hfgna5nogttqgud3ut6t2craprjp AT 6u5dgtopjfig>
 <xop64tmb4ijtfr62nrrsn4dzmpk4cvaru53tuarvmijsvqhyil AT 5ozkz7zhfz4x>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <xop64tmb4ijtfr62nrrsn4dzmpk4cvaru53tuarvmijsvqhyil@5ozkz7zhfz4x>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>,
        Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple