[Bug libc/30262] New: execvp() disobeys POSIX requirement on preserving $0 to script

["eblake at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30262

            Bug ID: 30262
           Summary: execvp() disobeys POSIX requirement on preserving $0
                    to script
           Product: glibc
           Version: 2.39
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: eblake at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Ever since glibc first implemented ENOEXEC fallback to the shell execution of a
script (see commits 6a032d81 and a1c46301bb back in 1996), it has passed
"/bin/sh" (well, _PATH_BSHELL) as the argv[0] of the new shell process, which
loses out on the original argv[0] of the exec[lv]p() caller.  Current POSIX
wording says this is wrong; and in fact, FreeBSD updated their libc in 2020 to
fix the same compliance bug:
https://cgit.freebsd.org/src/commit/?id=301cb491ea
and since they didn't get a lot of complaints, at least the BSD world didn't
have too many scripts where the change in $0 from "sh" to the original filename
in an ENOEXEC fallback mattered in practice.

However, I will also point out that passing argv[0] unchanged breaks busybox sh
(see https://bugs.busybox.net/show_bug.cgi?id=15481).  If the intent is to
provide a known $0 to the shell script, the as-if rule may let us get by with
other means for passing "sh" as argv[0] to the shell but still giving the shell
enough information to set $0.

The as-if rule might let us use ("/bin/sh", "sh", "-c", ". quoted_filename",
argv[0], ...) or ("/bin/sh", "sh", "-c", "exec -a \"$0\" quoted_filename
\"$@\"", argv[0], ...) if we want to avoid breaking systems where /bin/sh is
busybox, but still get $0 set to the POSIX-mandated name.  (The former has
issues on sh where . parses files as a compound_command rather than a program -
yes, the difference is observable when it comes to alias handling; the latter
has problems on sh where 'exec -a' is not implemented, since POSIX doesn't
mandate it).

I've opened a bug with the Austin Group seeing if they will relax the standard
to allow our behavior of passing "sh" rather than arg0 when hitting the ENOEXEC
fallback (note that because of kernel handling of #! lines, and most scripts
being installed with a shebang, it is surprisingly rare that glibc even sees
ENOEXEC in the first place):
https://www.austingroupbugs.net/view.php?id=1645

It's probably worth waiting for the Austin Group conversation to settle before
we decide which change (if any) is needed, given that unlike the FreeBSD world,
we really do risk breaking systems where /bin/sh is from busybox.

-- 
You are receiving this mail because:
You are on the CC list for the bug.