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

[Poul-Henning Kamp]

--------
In message <20180105221330.GD95035 at spindle.one-eyed-alien.net>, Brooks Davis writes:

>> I would argue the opposite.  There are very few reasons why close(s) would
>> ever fail, and the most likely is EBADF.  EBADF indicates a programming
>> bug, like a double close or use of an uninitialized variable.  Those could
>> easily turn into worse bugs in the future.  So I think the best course of
>> action is to check the return code, assert() on EBADF, and ignore, or
>> possibly log, other errors.

I fully agree on the seriousness of EBADF from close, but want to note
that close (2) used on sockets return a bestiarium of errors depending
on how the remote slammed the door.

>For this specific case, I think there would be value in an option to
>have the kernel kill any process that calls close(fd) where fd != -1
>where EBADF would be returned.

I think -current ought to be much more paranoid towards bugs.

When I added phkmalloc to -current many years ago, I set the default
flags to AJ and the first program which exploded on me was fsck(8),
and the next dozen or so were all setuid or setgid.

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.

So yes please, make libc and the kernel complain about anything
which looks like programming errors in -current, but hold off on
the process-killing, and make it possible to silence these complaints
at boot-time.

Maybe we should simply add a "bootparanoia" flag like we have "bootverbose" ?


-- 
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.