Is it considered to be ok to not check the return code of close(2) in base?

[Poul-Henning Kamp]

--------
In message <CAG6CVpULXoq6w4Xb+iSJ08phFuiCPhEod25Y4Am5PN9R=R5iZQ at mail.gmail.com>, Conra
d Meyer writes:
>On Fri, Jan 5, 2018 at 2:34 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> Brookes suggestion, while well intentioned, wouldn't get very far,
>> because it is common for shells and shell-like programs to do:
>>
>>         for (i = 3; i < ALOT; i++)
>>                 (void)close(i);
>>
>> To get rid of unwanted filedescriptors from syslog(3), getpwent(3) etc.
>> in the child process.
>>
>> Yes, I know about closefrom(2), but a lot of programs still don't use it.
>
>Hi,
>
>That seems like a good way to quickly identify programs in base that
>still do not use closefrom().

Absolutely, by all means *identify* these programs, but before you start
*killing* them, make sure you your system can actually function:

	$ cd /usr/src/bin/sh
	$ find . -name '*.c' -print | xargs grep closefrom
	$ cd /usr/src/contrib/tcsh
	$ find . -name '*.c' -print | xargs grep closefrom
	$ 

As I said:  I'm all for making the -current kernel more paranoid
about userland, but log the results to syslog (with rate-limiting!),
don't just kill the process.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.