Re: kern/59498: Add missing POSIX O_CLOFORK flag

["Ricardo Branco via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Ricardo Branco <rbranco%suse.de@localhost>
To: Robert Elz <kre%munnari.OZ.AU@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: Tue, 1 Jul 2025 21:16:22 +0200

 On 7/1/25 9:05 PM, Robert Elz wrote:
 >      Date:        Tue, 1 Jul 2025 19:20:47 +0200
 >      From:        Ricardo Branco <rbranco%suse.de@localhost>
 >      Message-ID:  <78c4992b-b5b6-493b-8eb2-594df8990ad6%suse.de@localhost>
 >
 >    | 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
 
 That sounds like a reasonable compromise.
 
 FWIW, FreeBSD recently introduced the FD_RESOLVE_BENEATH flag.
 
 I identified a number of places where FD_CLOEXEC is naively set
 without ORing with the results from F_GETFD, but first wanted to
 check whether you want to support this flag at all.