X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EDD84385B52E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1681850981;
	bh=/23COi+ErjEFKv2ALb/JnKyi8SY20mAzQ6abyFHDfoQ=;
	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=JiLeXkxS/VosIkWlhl0cT8twXLW8DCijvtAYswnYOQIc1WfM0ucKySHWL7DxXs1SW
	 yk0mtEYBhU0ZrGqQAI001tkDguvLvczR621Nh3Hw5qx0uSTREsRTLINgi24mvtzE9i
	 PU+5jadw0fxv3ioWEtZ7izKiJtsK/gjrbF4ctS1o=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5891385841E
X-MC-Unique: F_vYE9wcMuKvty1KjHIP_Q-1
Date: Tue, 18 Apr 2023 15:49:17 -0500
To: Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com
Subject: Re: posix_spawn facility
Message-ID: <xsn3qmrcprucviwtwoehm5hfgna5nogttqgud3ut6t2craprjp@6u5dgtopjfig>
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>
MIME-Version: 1.0
In-Reply-To: <ZD5h973pS0tVenD0@calimero.vinschen.de>
User-Agent: NeoMutt/20230407
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Disposition: inline
X-Spam-Status: No, score=-3.8 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_H2, 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
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: Eric Blake via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Eric Blake <eblake AT redhat DOT com>
Content-Type: text/plain; charset="utf-8"
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>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 33IKo4rR016419

On Tue, Apr 18, 2023 at 11:25:11AM +0200, Corinna Vinschen via Cygwin wrote:
> Hi Bruno,
> 
> On Apr 17 20:44, Bruno Haible via Cygwin wrote:
> > Hi Corinna,

Jumping in to this conversation a bit belatedly, but as someone on the
Austin Group that can try to get an answer upstream...

> But I'm not *that* happy with the change yet, for two reasons.
> 
> First, the security risk outlined in
> https://sourceware.org/bugzilla/show_bug.cgi?id=13134#c0 doesn't
> actually exist on Cygwin, because we don't implement setuid/setgid
> executables.  You can set the mode bits, but they are not acted upon.

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.

> 
> From the above bugzilla entry I take it that on glibc, both
> functions tried to run the shell if the executable isn't recognized
> (up to commits d96de9634a33 / 13adfa34aff).
> 
> However, on Cygwin, only posix_spawnp does that,but not posix_spawn.
> 
> In fact, I read the POSIX descriptions in terms of these functions quite
> thoroughly, and at no point I see it mentioned that posix_spawnp shall
> *not* work like exevlp/execvp.  The crucial difference between posix_spawn
> and posixc_spawnp is described in an interestingly vague way:
> 
>   posix_spawnp() interprets the second parameter more elaborately than
>   posix_spawn().
> 
> If I missed the point in the POSIX docs, please tell me.

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.

> 
> So, again, the patch is simple.  But it's kind of a pity that the change
> in glibc has been made without a bigger discussion.  Right now, it looks
> like the glibc change to posix_spawn was correct, but the change to
> posix_spawnp was arbitrary.
> 
> 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 ;)

> 
> > Btw, there are two more functions in the posix_spawn family meanwhile:
> >   * posix_spawn_file_actions_addchdir_np
> >     implemented by glibc [1], musl libc, macOS, FreeBSD [2], Solaris ≥ 11.3
> >     used by a few packages (Firefox, Chromium, Rust)
> >   * posix_spawn_file_actions_addfchdir_np
> >     implemented in glibc, musl libc
> >     but not used by any package so far [3].
> > 
> > The next POSIX will contain these functions (without the _np suffix).[4]
> 
> Thanks for the pointers.  I'm not sure I'll have the time to implement
> them soon, but I put them on my list for 3.5.0.  Patches welcome!
> 
> 
> Thanks,
> Corinna

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.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