Re: posix_spawn facility

[Eric Blake <eblake@redhat.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