Re: [PATCH] progname: don't segfault when argv is NULL

[Eric Blake]

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