Re: [Libguestfs] [libnbd PATCH v4 0/2] lib/utils: introduce async-signal-safe execvpe()
On Wed, Mar 22, 2023 at 03:45:17PM +0100, Laszlo Ersek wrote:
On 3/21/23 18:28, Eric Blake wrote:
> it is indeed a bug in busybox now that POSIX is moving towards
> standardizing realpath, so I've filed it:
> https://bugs.busybox.net/show_bug.cgi?id=15466
I've found another busybox bug.
The "/bin/sh" utility is provided by busybox as well (via the usual
symlinking).
Per POSIX, if
execvp(file, { argv[0], argv[1], ..., NULL })
were to fail with -1/ENOEXEC, then execvp() must retry "as if" with
execv(<shell path>, { argv[0], file, argv[1], ..., NULL })
In other words, if direct execution of "file" failed because "file"
"has the appropriate access permission but has an unrecognized format", then
execvp() is required to try executing "file" as a shell script. For that,
<shell path> is left unspecified by POSIX, but the arguments of the shell are
specified:
- Argv[0] remains the same. That is, what we wanted "file" to know itself as,
is what we now want *the shell executable* to know itself as.
- argv[1] becomes "file" -- this is the script that the shell is supposed to
run.
- argv[2] and onwards become positional parameters $1, $2, ... for the shell script.
And the argv[0] specification is what's violated by busybox, because if argv[0] is
anything other than "sh", then the busybox binary doesn't recognize itself
as the shell!
The as-if rule might allow us to invoke something like execv(<shell
path>, {"sh", "-c", munge(file), argv[0], argv[1], ..., NULL},
where
munge(file) produces ". quoted_file" as a way to source the contents
of file in the current shell environment, without ';' or other
metacharacters in file causing us to go off the rail. But getting
munge(file) to work correctly without post-fork() malloc() is going to
be just as difficult (our _init function pre-fork would have to
pre-munge every candidate name...)
The busybox list is annoying - it won't let me post without first
being a subscriber (I attempted to post a quick patch to implement
'readlink -- foo'; implementing 'realpath -- foo' was not as quick).
But if they let me on the list, I'll certainly bring it to their
attention that their 'sh' behavior is indeed awkward.
The simplest way to demonstrate the bug is this:
bash-5.2$ ( exec -a foobar /bin/sh <<< "echo hello" )
foobar: applet not found
And then, another way to demonstrate the same busybox issue... lets us, in fact, discover
a musl bug in turn!!!
I'll discuss that more in reply to your followup mail.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org