bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Meyering
Subject: Re: [PATCH] progname: don't segfault when argv is NULL
Date: Sat, 05 Dec 2009 09:14:25 +0100

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]