Bruno Haible wrote:
>> Ok to apply the patch below?
>> Without it, anyone can make nearly any coreutils program segfault
>> with this simple recipe:
>>
>> printf '%s\n' '#include <unistd.h>' 'int main(int c, char**v)' \
>> '{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out /bin/cat
>>
>> While that usage of execve is in violation of POSIX
>
> One of the purposes of specifications is to avoid redundant checking
> of arguments. Imagine, if strlen, strcpy, etc. would have to handle NULL
> pointers, how many extra conditional statements a CPU would have to
> execute.
Hi Bruno,
If you're convinced it should be like the str* functions,
then I suggest you declare those functions with the "nonnull" attribute.
> 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."
>
> In summary, one can argue for bug-tolerant behaviour, within limits.
> This case here is way off-limits.
"way off-limits"? Yes, I was reluctant to propose this change --
for the same reason you're reluctant to accept it.
Sure, it's annoying, but the compromise would be for a good cause.
The added code is tiny and non-invasive, and would save over 100 known
calling programs from having to add similar code.
I hope you reconsider.
The idea of carrying the identical progname.c.diff patch in 6 different
packages is not appealing. *Everyone* uses set_program_name -- or should.
Why do I care?
Just 3 days ago I received a private report of sleep segfaulting.
Unfortunately, it was not reproducible. I would like to be able
to eliminate set_program_name as a possible point of NULL-dereference.
