View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00019601003.1(2024)/Issue8System Interfacespublic2025-11-20 17:172025-11-20 17:17
Reportersteffen Assigned To 
PriorityhighSeverityEditorialTypeEnhancement Request
Status NewResolutionOpen 
Namesteffen
Organization
User Reference
Sectionfcntl
Page Number246
Line Number8633
Interp Status
Final Accepted Text
Summary0001960: fcntl(): add F_DUPFD_CLOFORKEXEC flag
DescriptionThe peculiarity with the approach documented on page 909, APPLICATION USAGE of fcntl(), lines 31036 to 31041, regarding


In order to set both FD_CLOEXEC and FD_CLOFORK when duplicating a file descriptor,
applications should use F_DUPFD_CLOFORK to obtain the new file descriptor with
FD_CLOFORK already set, and then use F_SETFD to set the FD_CLOEXEC flag on the new
descriptor.[.]


is that the file descriptor is in an intermediate state until three system calls have successfully been performed: the dup as such, the fetching of the flags, plus the setting of the adjusted flags.

For a generic library function wrapper which states "we do return the duplicated descriptor in fork+exec state" this thus requires special actions to take care for a.k.a. avoid signal caused jumps, and/or fd accounting (list of created fds, and their state, a.k.a. "partially constructed", for example).

As another remark, in today's world of CPU side-channel attack mitigations, system calls have become much more expensive.
(Data point: compilation of the Linux kernel 6.1 series on the author's box is forty (40) percent slower with/out mitigations.)

Given that we talk about adding "just another bit" to the flags of a file descriptor, and that dup3(2) and open(2) both allow setting both flags in one go, not being able to F_DUPFD with both flags set seems needlessly expensive, and even unnatural.
Desired ActionAdd a F_DUPFD_CLOFORKEXEC flag, the implementation of which appears trivial.

On page 246, fcntl.h header, add, after line 8633,

F_DUPFD_CLOFORKEXEC
Duplicate file descriptor with the close-on-fork flag FD_CLOFORK and the close-on-exec flag FD_CLOEXEC set.

On page 835, system interfaces, dup/dup2/dup3, RATIONALE, lines 28573 ff., change

The safe counterpart for avoiding the same race with dup( ) is the use of the F_DUPFD_CLOFORK or F_DUPFD_CLOEXEC action of the fcntl( ) function.

to

        The safe counterpart for avoiding the same race with dup( ) is the use of the F_DUPFD_CLOFORK, F_DUPFD_CLOEXEC or F_DUPFD_CLOFORKEXEC action of the fcntl( ) function.

On page 901, system interfaces, fcntl, add after line 30684

F_DUPFD_CLOFORKEXEC
Like F_DUPFD, but the FD_CLOFORK flag and the FD_CLOEXEC flag associated with the new file descriptor shall be set.

On page 906, ditto, after line 30901, add

F_DUPFD_CLOFORKEXEC
        a new file descriptor

and on page 907 adjust the error conditions of EINVAL and EMFILE to include the new flag accordingly.

On page 909, APPLICATION USAGE, remove the two sentences starting at line 31036 and ending at line 31041,

In order to set both FD_CLOEXEC [.] because FD_CLOFORK has not yet been set.)
TagsNo tags attached.

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2025-11-20 17:17 steffen New Issue