The current glibc implementation of posix_spawn() invokes /bin/sh if execve sets errno to ENOEXEC. This is not specified by the POSIX.2004 definition (http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html), is different from the behavior of the sample implementation in the POSIX.2004 rationale section (http://pubs.opengroup.org/onlinepubs/009604599/xrat/xsh_chap03.html), and seems to have the same security risks that system() and popen() do in set{u,g}id executables. In particular, the Rationale section says "The effective behavior of a successful invocation of posix_spawn() is as if the operation were implemented with POSIX operations as follows:", which as I've said is followed by an implementation that behaves differently than the glibc posix_spawn(). This appears to be non-compliant behavior.
Confirmed. My cynical prediction is that this bug will be ignored either for "compatibility reasons" or because of the fact that someone obviously went to a bit of trouble to write that completely wrong code for shell invocation that doesn't even belong in spawni.c. Please prove me wrong...
Created attachment 5915 [details] Trivial fix This patch removes the non-compliant behaviour.
You really don't know what binary compatibility means, right? git contains a change.
(In reply to comment #3) > You really don't know what binary compatibility means, right? git contains a > change. Sorry, my fix was far too naive. I shouldn't have submitted that patch at all if I wasn't going to take the time to get it right.
The change from 2011 had no effect on the Hurd. The Hurd case has been fixed now, by Samuel Thibault: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=13adfa34aff03fd9f1c1612b537a0d736ddb6c2b