[PATCH] argv[0] of execvp when ENOEXEC

Rich Felker dalias at aerifal.cx
Wed Aug 21 19:32:06 UTC 2013


On Wed, Aug 21, 2013 at 04:44:13PM +0000, u-uclibc-9coy at aetey.se wrote:
> Hello,
> 
> On Wed, Aug 21, 2013 at 11:06:04PM +0800, Wei-cheng Wang wrote:
> >     The argument arg0 should point to a filename that is associated
> >     with the process being started by one of the exec functions.
> 
> "should" is not "must", it is a recommendation, not a well defined one either:
> "point to" is uncertain (absolute? from the caller's working directory? via
> the PATH?)

Indeed. "Should" is a recommendation for what the application calling
execvp/execlp should do, and neither a recommendation nor a
requirement on what the implementation should do. Here, "the argument
argv0" refers to the argv0 (or argv[0]) passed to execlp (or execvp)
by the application.

> >   If, by the standrd, arg0 is not necessary <shell path>,
> >   I agree busybox should fix it, not uClib to workaround it.
> 
> I do not think there is any "fix" as the choice to analyze the unreliable
> argv[0] is a workaround for the API deficiency. This workaround is not
> feature-complete either. Busybox and similar tools are stretching POSIX
> to the limits and a bit beyond :)

There are two possible "solutions" for this. One is to have busybox
use the AT_EXECFN auxv entry rather than argv[0] to determine which
applet to run. The other is to replace all the symlinks to busybox
with symlinks to a single text file containing: "#!/bin/busybox". This
will cause the kernel to effectively rewrite:

    execl(pathname, argv0, argv1, argv2, ...,);

to:

    execl("/bin/busybox", "/bin/busybox", pathname, argv1, argv2, ...);

and then busybox will read the command name from its first argument
rather than from argv[0].

Either solution fixes the case where the caller provides a meaningless
argv[0] but uses the correct symlink pathname to exec busybox. Neither
fixes the case where the caller has made a new symlink to the command
by a different name, or where fexecve is being used on a file
descriptor for the executable. In fact in the case of fexecve, they
make the situation worse, since the caller _might_ be passing the
right name as argv[0], but the pathname passed to the execve syscall
will be useless for determining which applet to run.

Rich



More information about the uClibc mailing list