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.