On Wed, Mar 22, 2023 at 04:53:42PM +0100, Laszlo Ersek wrote:
The solution is that glibc *too* has a bug, and that bug hides the
busybox bug. Namely, in glibc, going back to historical commit
commit 6a032d81581978187f562e5533a32e0a6a3d352b (tag: cvs/libc-960210)
Author: Roland McGrath <roland(a)gnu.org>
Date: Sat Feb 10 10:00:27 1996 +0000
Sat Feb 10 04:18:48 1996 Roland McGrath <roland(a)churchy.gnu.ai.mit.edu>
* posix/execvp.c: If execv fails with ENOEXEC, run the shell on
the file.
Fri Feb 9 11:46:45 1996 Roland McGrath <roland(a)churchy.gnu.ai.mit.edu>
* time/Makefile (CFLAGS-zdump.c, CFLAGS-zic.c, CFLAGS-ialloc.c,
CFLAGS-scheck.c): Use -DNOID instead of -Wno-unused.
* hurd/Makefile (user-interfaces): Added hurd/tioctl.
(note the date: 1996!), the POSIX-mandated fallback
execv(<shell path>, { argv[0], file, argv[1], ..., NULL })
is not being done. Instead, the following is done:
execv(<shell path>, { <shell path>, file, argv[1], ..., NULL })
In other words, the original argv[0] is not preserved, but is replaced by <shell
path>. (Look for _PATH_BSHELL in said historical glibc commit, and also in today's
glibc file "posix/execvpe.c".)
Aside - what a funny filename, since execvpe() is a glibc extension
not in POSIX ;)
I've now filed a bug report to the Austin Group:
https://www.austingroupbugs.net/view.php?id=1645 And while researching
for that, I found that FreeBSD had the same bug up until 2020:
https://cgit.freebsd.org/src/commit/?id=301cb491ea
On the other hand, the fact that FreeBSD changed and didn't suffer an
immediate backlash of breaking programs means that glibc might
consider such a change, despite the length of the history it would be
changing. So I'll also file a bug to glibc as part of my efforts.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org