Bruno Haible <bruno <at> clisp.org> writes: > > While that usage of execve is in violation of POSIX > > One of the purposes of specifications is to avoid redundant checking > of arguments.
But this is NOT redundant. > It makes sense to be "lenient in what you accept", for example when the > spec is unclear, or the violation can easily occur without clear programming > error. But this is not the case here. POSIX's execve spec: > "The argument arg0 should point to a filename that is associated with > the process being started by one of the exec functions." Yes, it is impossible for a POSIX-compliant environment to trigger this failure case. But not all the world is POSIX. And what's worse, the bug is triggered based on the actions of the parent process, not the current process. I'm all for skipping redundant NULL checks if the current process didn't do due diligence, but by not making set_program_name robust, you are effectively asking for every client of set_program_name to do the NULL check if we think it is an important enough 'gotcha' to avoid. Think about the *_safer modules. The Austin Group is considering a proposal[1] that would make it non-conforming to invoke execve without the child process having fd 0, 1, and 2 properly set. But we still want to use the *_safer modules, because that is a protection against the malicious/non-compliant actions of a bad parent process, even though it is redundant in a compliant environment. [1] http://austingroupbugs.net/view.php?id=173 > > nothing prevents a set_program_name caller from calling > > the function with a NULL argument. Hence, we should handle it. > > I disagree. The specs in progname.h say: > > /* Programs using this file should do the following in main(): > set_program_name (argv[0]); > */ And since argv[0] can be NULL (although only in a non-conforming situation), I think a single NULL check in set_program_name is the place to protect the rest of the program from having to worry about the issue. -- Eric Blake
