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