Re: kern/59498: Add missing POSIX O_CLOFORK flag

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59498; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Ricardo Branco <rbranco%suse.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/59498: Add missing POSIX O_CLOFORK flag
Date: Wed, 02 Jul 2025 02:05:35 +0700

     Date:        Tue, 1 Jul 2025 19:20:47 +0200
     From:        Ricardo Branco <rbranco=40suse.de>
     Message-ID:  <78c4992b-b5b6-493b-8eb2-594df8990ad6=40suse.de>
 
   =7C In this implementation, O_CLOFORK is cleared on exec,
 
 That's fine, but not related to what I asked.
 
 Typically O_CLOFORK is set by library functions to guard against
 possible other threads forking while a temporary fd is open.
 Those temporary fd's can last for noticeable time, and can be
 revealed to the application code.
 
 The application might want to see if close-on-exec has been set
 for the fd (for some reason) and use fcntl(F_GETFD) to do it, and
 never having heard of O_CLOFORK (or FD_CLOFORK) simply assumes that
 the non-zero return means O_CLOEXEC is set on the fd.
 
 I think we need an audit of applications (which includes library code
 that they might call) to examine all fcntl(F_GETFD) (and fcntl(F_SETFD))
 calls, and make sure they are doing the right thing, before the
 O_CLOFORK mechanism is exposed to user space in any way (it doesn't hurt
 to have it in the kernel, as long as nothing, tests excepted, ever
 sets it).
 
 kre