Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001318 [1003.1(2016)/Issue7+TC2] System Interfaces Comment Enhancement Request 2020-01-12 10:50 2020-01-13 16:38
Reporter nate_karstens View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Nate Karstens
Organization Garmin
User Reference
Section fcntl, open, socket
Page Number Unknown
Line Number Unknown
Interp Status ---
Final Accepted Text
Summary 0001318: Define close-on-fork flag
Description Certain interfaces (like system(), popen(), etc.) are non-atomic in that their implementation first calls a fork() and then an exec(). This creates a race condition in certain scenarios. Please see www.mail-archive.com/austin-group-l@opengroup.org/msg05324.html">https://www.mail-archive.com/austin-group-l@opengroup.org/msg05324.html [www.mail-archive.com/austin-group-l@opengroup.org/msg05324.html" target="_blank">^] and resulting discussion for a description of one such condition.

Issue 1317 already requests enhancements to these interfaces, but this particular issue would also be solvable if there was a close-on-fork flag (similar to close-on-exec, but the file descriptor is closed in the child process after a fork).
Desired Action Add the following to fcntl()/F_DUPFD:

The FD_CLOFORK flag associated with the new file descriptor shall be cleared to keep the file open in the child process after a fork.

Add the following to fcntl()/F_SETFD

If the FD_CLOFORK flag in the third argument is 0, the file descriptor shall remain open in the child process after a fork(). Otherwise, the file descriptor shall be closed in the child process after a fork().

Add the following to fcntl():

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

Additional changes to the RETURN VALUE and ERRORS sections may be necessary as well.

Add the following to open():

O_CLOFORK
    If set, the FD_CLOFORK flag for the new file descriptor shall be set.

POSIX does not currently specify SOCK_CLOEXEC, but this would be a useful addition. Add the following to socket():

SOCK_CLOEXEC
    If set, the close-on-exec (FD_CLOEXEC) flag for the new file descriptor shall be set.
SOCK_CLOFORK
    If set, the close-on-fork (FD_CLOFORK) flag for the new file descriptor shall be set.

In hindsight, it seems like it would have been preferable to have the default behavior be to close all file descriptors when the process forks, and have flags to override that behavior on an individual basis. Submitter cannot think of a way to do that and maintain backwards-compatibility, short of defining new system calls, but the idea seems like it would be worth considering.
Tags No tags attached.
Attached Files

- Relationships
related to 0000411Resolvedajosey 1003.1(2008)/Issue 7 adding atomic FD_CLOEXEC support 

-  Notes
(0004725)
kre (reporter)
2020-01-13 07:28

The wording:

   If the FD_CLOFORK flag in the third argument is 0, the file descriptor
   shall remain open in the child process after a fork(). Otherwise, the
   file descriptor shall be closed in the child process after a fork().

is bizarre, and (I suspect) is influenced by the odd view of how fork()
and file descriptors should have been handled. The more common way to
write this would be

   If the FD_CLOFORK flag in the third argument is set, the file descriptor
   will be closed in the child process after a successful fork() operation,
   otherwise the file descriptor shall remain open in the child after a fork()

with appropriate xref tags added.

Then wrt:

    Add the following to fcntl():

    F_DUPFD_CLOFORK

please, no, we already have F_DUPFD_CLOEXEC which is bad enough, if
we add a new one like this, we'd also need

    F_DUPFD_CLOEXEC_CLOFORK

so that both flags can be set. F_SETFD is enough for all of this, but
to add a new flag to that is problematic, lots of (older) applications
assume that close-on-exec is its only possibility, as for decades that
has been trus (and there was no constant defined, so the result from
F_GETFD is often simply tested against 0, if not 0, close on exec is
assumed, and 1 is used for F_SETFD to set close-on-exec).

If something is needed for atomic operation, add a F_DUFPD variant where
the arg is the flags, rather than the lowest desired fd number, or simply
standardise dup3() which has a flags arg, and could easily be made to have
a "next available bigger than" flag as well as the close-on-exec (and
presumably a new close-on-fork) flag it already accepts (to make dup3()
be able to act as an alternative to fcntl(F_DUFPD) in a reasonable way,
without adding more args to fcntl().

Lastly (for now):

    In hindsight, it seems like it would have been preferable to have the
    default behavior be to close all file descriptors when the process forks

Nonsense. All of this is brought about by the horrid threading design that's
been thrust upon us (and yes, I know it came about based upon implementations
that were entirely in-process hacks initially, with no kernel support at all).

Without threads there's no reason for any of this. With a sane thread
design (which would largely be something like a sfork() call - fork but
share the text (as more or less always these days anyway) and the data
segments - but producing separate processes. All the synchronisation
mechanisms would still be needed, but none of this fd nonsense, as fd's
would only be shared by design, not by accident.

However we have what we have, so I am not objecting to the solution proposed
in principle (just some details) - also not promising that any of it will
ever get implemented in NetBSD (none of this is there now). (This is not
my area there, so someone else, with community input, would make that call.)
(0004728)
eblake (manager)
2020-01-13 16:38

Standardization of dup3() and SOCK_CLOEXEC is already the subject of 0000411

- Issue History
Date Modified Username Field Change
2020-01-12 10:50 nate_karstens New Issue
2020-01-12 10:50 nate_karstens Name => Nate Karstens
2020-01-12 10:50 nate_karstens Organization => Garmin
2020-01-12 10:50 nate_karstens Section => fcntl, open, socket
2020-01-12 10:50 nate_karstens Page Number => Unknown
2020-01-12 10:50 nate_karstens Line Number => Unknown
2020-01-13 07:28 kre Note Added: 0004725
2020-01-13 16:37 eblake Relationship added related to 0000411
2020-01-13 16:38 eblake Note Added: 0004728


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker