Arguments to execve
Carlos O'Donell
carlos@redhat.com
Tue Jun 11 20:42:00 GMT 2013
On 06/11/2013 04:24 PM, Peter LaDow wrote:
> (I posted this on eglibc, but since this is not specific to the
> differences between glibc and eglibc, it was pointed out that this
> list is more appropriate.)
>
> According to the man page for execve():
>
> argv is an array of argument strings passed to the new program. By
> convention, the first of these strings should contain the filename
> associated with the file being executed. envp is an array of strings,
> conventionally of the form key=value, which are passed as environment
> to the new program. Both argv and envp must be terminated by a NULL
> pointer. The argument vector and environment can be accessed by the
> called program's main function, when it is defined as:
>
> And of course we all know that argv and envp should NULL terminated
> arrays (the key sentence being: "Both argv and envp must be
> terminated by a NULL pointer.")
>
> However, we ran into a case where we had some old code that used execve such as:
>
> char *cmd[] = { "/path/to/command", NULL };
> execve(cmd[0], cmd, NULL);
>
> And it works fine. However, this obviously violates the documented
> usage. Wondering why this didn't fail (at least with a segfault), it
> appears that eglibc (and glibc) just pass these parameters directly to
> the syscall unchecked. Digging into the actual sycall in the kernel
> (fs/exec.c) it appears that a NULL parameter is silently transformed
> into a NULL terminated array.
>
> Now, the stub in posix/execve.c DOES check that the parameters and
> return EINVAL if a NULL argument is passed. Yet the man pages
> (neither 2 nor 3posix) do not indicate that EINVAL is returned if a
> NULL parameter is passed.
>
> So, I guess my question is: would a patch that checks the arguments
> (along with an appropriate man page update to the appropriate group)
> be useful? Or is this behavior expected and a change would be quite
> unwelcome?
The standard dictates what should happen for your program to be portable
and standards conforming.
The above code you quote is not portable since it violates the standard.
We are not going to change the behaviour of execve on Linux to return
EINVAL if envp is NULL since that might break non-portable programs
on Linux that currently work. We would break these programs for no
reward.
It might be useful to document this shortcut of using NULL in the
manual pages (provided by the Kernel Man Pages project) and the glibc
manual (part of the glibc source e.g. manual/*).
Cheers,
Carlos.
More information about the Libc-help
mailing list