X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 424D23858C5F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1681851655;
	bh=v3/Jqmstskv271K6P4iZbHlrms0rH0IkIjE9V1DC/uk=;
	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=bC9PBk9cpcx0UT0NmjfN9aO2viLDqHfzkicPvIu6uF1KBwIy8NB6khrrL5Hx0pgK6
	 V5gwQQ3ycIYMSG0ev7DQ9mWiODuLZV8uItMdxkWUL/1MPs+OhpfgQTfNUoU+sztcdf
	 +whbPloSwM6OXR/zrXDiISFwDludlMs2I8DM91wM=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7B68C3858D1E
Date: Tue, 18 Apr 2023 23:00:39 +0200
To: Eric Blake <eblake AT redhat DOT com>
Subject: Re: posix_spawn facility
Message-ID: <ZD8E9ywCKBhmtx+O@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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <xsn3qmrcprucviwtwoehm5hfgna5nogttqgud3ut6t2craprjp@6u5dgtopjfig>
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 Apr 18 15:49, Eric Blake via Cygwin wrote:
> On Tue, Apr 18, 2023 at 11:25:11AM +0200, Corinna Vinschen via Cygwin wrote:
> Jumping in to this conversation a bit belatedly, but as someone on the
> Austin Group that can try to get an answer upstream...

Many thanks for your input, it's highly appreciated.

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

My point here is mostly directed to this gnulib testcase.  It tests
posix_spawnp in terms of an undefined behaviour, and if it doesn't
behave in a certain way, it's deemed insecure.

I strongly doubt that this is the right thing to do.

That doesn't mean I'm refusing to change Cygwin to be aligned to
the behaviour of glibc or, even more important, to POSIX.

But the testcase *is* questionable.


> > Has anybody attempted to ask the Austin group to define this behaviour
> > in posix_spawnp more concise?  Is there a protocel from the Austin
> > group?  If not, wouldn't it be time to ask the Austin group?
> 
> Doing that now ;)

Thanks a lot!


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