From owner-freebsd-hackers@freebsd.org Fri Jan 5 22:34:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65628EC5582 for ; Fri, 5 Jan 2018 22:34:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0143373; Fri, 5 Jan 2018 22:34:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8E73927374; Fri, 5 Jan 2018 22:34:51 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w05MYach024175 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Jan 2018 22:34:36 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w05MYZow024174; Fri, 5 Jan 2018 22:34:35 GMT (envelope-from phk) To: Brooks Davis cc: Alan Somers , Yuri , Ian Lepore , Freebsd hackers list Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-reply-to: <20180105221330.GD95035@spindle.one-eyed-alien.net> From: "Poul-Henning Kamp" References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> <20180105221330.GD95035@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24172.1515191675.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 05 Jan 2018 22:34:35 +0000 Message-ID: <24173.1515191675@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:34:54 -0000 -------- In message <20180105221330.GD95035@spindle.one-eyed-alien.net>, Brooks Dav= is writes: >> I would argue the opposite. There are very few reasons why close(s) wo= uld >> ever fail, and the most likely is EBADF. EBADF indicates a programming >> bug, like a double close or use of an uninitialized variable. Those co= uld >> 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 !=3D -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 =3D 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@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= .