From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id DFF163858D1E; Tue, 18 Apr 2023 09:25:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFF163858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1681809913; bh=Rbmv78qEWrJ2VfEWxViiVPFVmo/kj7F0v6WH5L/X7No=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=ZvbTc92S1ZJGAbkrg2mtwzDA4snRePRWy0fZ5pHcyYxKbJm0MBwpaWtJZDdQEu/2m pYu4YpZPEkw5JKJVpL4sw1xFO1xETFOHmZNlvwP6h3zXgebI4vi9s2w8EdJ/YunK2L jmagd/n/aTf2gfnp33BCf668pzy7XBy298FhNTO8= Received: by calimero.vinschen.de (Postfix, from userid 500) id DF817A808C0; Tue, 18 Apr 2023 11:25:11 +0200 (CEST) Date: Tue, 18 Apr 2023 11:25:11 +0200 From: Corinna Vinschen To: Bruno Haible Cc: cygwin@cygwin.com Subject: Re: posix_spawn facility Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: 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 Content-Transfer-Encoding: 8bit In-Reply-To: <5022555.upeRZZJTqa@nimes> List-Id: Hi Bruno, On Apr 17 20:44, Bruno Haible via Cygwin wrote: > Hi Corinna, > > > > Would it be possible to change Cygwin's posix_spawnp implementation, > > > so that both tests succeed? > > > > Basically, yes, but... > > Thanks! > > > > Disclaimer: I have done my tests with Cygwin 2.9.0; so, if things have > > ^^^^^^^^^^^^ > > 2017-09-07 > > > > I'm a bit puzzled. You quote that only Cygwin 3.1.7 has the fixed > > posix_spawn, but then you test this with a version three years older? > > I have now verified that the findings with Cygwin 3.4.6 are the same as > with Cygwin 2.9.0. I had expected that, based on browsing through the > Cygwin git history; I confirm it now. Thanks a lot! The patch is actually simple. 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. 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. >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. 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? > 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