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 <rol...@gnu.org>
> Date:   Sat Feb 10 10:00:27 1996 +0000
> 
>     Sat Feb 10 04:18:48 1996  Roland McGrath  <rol...@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  <rol...@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
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs

Reply via email to