X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 6A6B1385842A
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1690829947;
	bh=fB2XWcEcyqNECM7UD5oWqfpWMiiPUCNfKoJ6J6Top5U=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=fJ4MXBW9LTIInLlodx68ugrXubQdIKX/yw2rGRrttr5FDXDmMS0ntYgPIafm4ihX0
	Tvq4Lduaqx8x5lKnY3A6tD6z63U+tHIchIQEs3kw2JAqe3COLeu1YGAPCq03jjBS3z
	b42WSTuyoepYpP7Uk09vqtwoyAFUtBpDiFi43aWc=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 5CA513858D28
X-MC-Unique:	eva19znJMd2lbAsojYZOgQ-1
Date:	Mon, 31 Jul 2023 13:58:20 -0500
To:	Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com
Subject:	Re: posix_spawn facility
Message-ID:	<xop64tmb4ijtfr62nrrsn4dzmpk4cvaru53tuarvmijsvqhyil@5ozkz7zhfz4x>
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>
MIME-Version:	1.0
In-Reply-To:	<xsn3qmrcprucviwtwoehm5hfgna5nogttqgud3ut6t2craprjp@6u5dgtopjfig>
User-Agent:	NeoMutt/20230517
X-Scanned-By:	MIMEDefang 3.1 on 10.11.54.2
X-Mimecast-Spam-Score:	0
X-Mimecast-Originator:	redhat.com
X-Spam-Status:	No, score=-3.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
	DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
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:	Eric Blake via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Eric Blake <eblake AT redhat DOT com>
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>

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

Yes, it's odd that ENOEXEC normally equates to status 126, but does
not do so for posix_spawn().  If you want to add an extention
POSIX_SPAWN flag (for use in posix_spawnattr_setflags()) to further
tweak things as an extension to the standard, that would probably be
reasonable, but without implementations already implementing and
relying on such extension flags, the Austin Group did not want to
visit that topic today.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org


-- 
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

- Raw text -