Re: posix_spawn facility

[Corinna Vinschen <corinna-cygwin@cygwin.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