|Anonymous | Login||2020-01-26 20:29 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Section||fcntl, open, socket|
|Final Accepted Text|
|Summary||0001318: Define close-on-fork flag|
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 firstname.lastname@example.org/msg05324.html">https://email@example.com/msg05324.html [firstname.lastname@example.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).
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():
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():
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():
If set, the close-on-exec (FD_CLOEXEC) flag for the new file descriptor shall be set.
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.|
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.
Add the following to fcntl():
please, no, we already have F_DUPFD_CLOEXEC which is bad enough, if
we add a new one like this, we'd also need
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.)
|Standardization of dup3() and SOCK_CLOEXEC is already the subject of 0000411|
|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|