[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Patches] Arguments to execve()
- To: patches@xxxxxxxxxx
- Subject: [Patches] Arguments to execve()
- From: Peter LaDow <petela@xxxxxxxxxxxxxxx>
- Date: Tue, 11 Jun 2013 10:19:38 -0700
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?
Thanks,
Pete
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches