[PATCH] argv[0] of execvp when ENOEXEC

[Rich Felker]

On Tue, Aug 20, 2013 at 02:02:27PM -0400, Rich Felker wrote:
> On Wed, Aug 21, 2013 at 12:42:57AM +0800, Wei-cheng Wang wrote:
> > Hi,
> > 
> > When execvp executes the file and gets NOEXECV, it shall execute
> > a command interpreter as if the process is invoked by sh, and the
> > argv[0] shall point to the filename being started.  Therefore,
> > a script file without hashbang (#!) is still executed by sh utility.
> > 
> > However, currently uClibc set argv[0] to be the filename of the script
> > itself instead of the name of shell, e.g., "/bin/sh", and it is
> > inconsistent with the behaviors of other libc (e.g., BSD libc, glibc,
> > bionic libc) and how Linux kernel passed interpreter as argv[0] in
> > binfmt_script.   Although it’s not mandatory in terms of POSIX.1, but
> > busybox relies on argv[0] for "sh" applet to be run.
> 
> POSIX mandates the current uClibc behavior:
> 
>   There are two distinct ways in which the contents of the process
>   image file may cause the execution to fail, distinguished by the
>   setting of errno to either [ENOEXEC] or [EINVAL] (see the ERRORS
>   section). In the cases where the other members of the exec family of
>   functions would fail and set errno to [ENOEXEC], the execlp() and
>   execvp() functions shall execute a command interpreter and the
>   environment of the executed command shall be as if the process
>   invoked the sh utility using execl() as follows:
> 
>   execl(<shell path>, arg0, file, arg1, ..., (char *)0);
> 
>   where <shell path> is an unspecified pathname for the sh utility,
>   file is the process image file, and for execvp(), where arg0, arg1,
>   and so on correspond to the values passed to execvp() in argv[0],
>   argv[1], and so on.

I'm actually beginning to doubt that POSIX requires the uClibc
behavior. Presumably the above text is trumped by the "as if" rule --
as long as a conforming application cannot observe a difference in
behavior between what a conforming shell would do with the above execl
call, and what the actual shell does with the actual execve syscall,
the rest should be up to the implementation.

I'm not entirely clear however on whether there would be observable
differences. If somebody is interested in pursuing this issue, I think
that should be studied.

Rich