A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1318 ====================================================================== Reported By: nate_karstens Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1318 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Nate Karstens Organization: Garmin User Reference: Section: fcntl, open, socket Page Number: Unknown Line Number: Unknown Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2020-01-12 10:50 UTC Last Modified: 2020-03-16 16:24 UTC ====================================================================== Summary: Define close-on-fork flag ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000411 adding atomic FD_CLOEXEC support related to 0001317 Require fork handlers to be called in c... ======================================================================
---------------------------------------------------------------------- (0004797) geoffclare (manager) - 2020-03-16 16:24 https://austingroupbugs.net/view.php?id=1318#c4797 ---------------------------------------------------------------------- On page 238 line 8018 section <fcntl.h>, change:<blockquote>The <b><fcntl.h></b> header shall define the following symbolic constant used for the <i>fcntl</i>() file descriptor flags, which shall be suitable for use in <b>#if</b> preprocessing directives. FD_CLOEXEC<blockquote>Close the file descriptor upon execution of an <i>exec</i> family function.</blockquote></blockquote>to:<blockquote>The <b><fcntl.h></b> header shall define the following symbolic constants used for the <i>fcntl</i>() file descriptor flags. The values shall be bitwise-distinct and shall be suitable for use in <b>#if</b> preprocessing directives. FD_CLOEXEC<blockquote>Close the file descriptor upon successful execution of an <i>exec</i> family function [SPN]and in the new process image created by <i>posix_spawn</i>() or <i>posix_spawnp</i>()[/SPN].</blockquote> FD_CLOFORK<blockquote>Close the file descriptor in any child process created from a process that has the file descriptor open; that is, the child shall not inherit the file descriptor.</blockquote></blockquote> On page 238 line 8032 section <fcntl.h>, change:<blockquote>O_CLOEXEC<blockquote>The FD_CLOEXEC flag associated with the new descriptor shall be set to close the file descriptor upon execution of an <i>exec</i> family function.</blockquote></blockquote>to:<blockquote>O_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on the new file descriptor.</blockquote> O_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on the new file descriptor.</blockquote></blockquote> On page 387 line 13167 section <sys/socket.h>, after the bug 411 text:<blockquote>SOCK_CLOEXEC<blockquote>Create a socket file descriptor with the FD_CLOEXEC flag atomically set on that file descriptor.</blockquote></blockquote>add:<blockquote>SOCK_CLOFORK<blockquote>Create a socket file descriptor with the FD_CLOFORK flag atomically set on that file descriptor.</blockquote></blockquote> On page 388 line 13195 section <sys/socket.h>, after the bug 411 text:<blockquote>MSG_CMSG_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on any file descriptors created via SCM_RIGHTS during <i>recvmsg</i>().</blockquote></blockquote>add:<blockquote>MSG_CMSG_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on any file descriptors created via SCM_RIGHTS during <i>recvmsg</i>().</blockquote></blockquote> On page 497 line 17263 section 2.5.1, change:<blockquote>A file descriptor is closed by <i>close</i>(), <i>_exit</i>(), or the <i>exec</i> functions when FD_CLOEXEC is set on that file descriptor.</blockquote>to:<blockquote>Several functions close file descriptors, including <i>close</i>(), <i>dup2</i>(), <i>_exit</i>(), the <i>exec</i> functions when FD_CLOEXEC is set on a file descriptor, <i>fork</i>() when FD_CLOFORK is set on a file descriptor, and <i>posix_spawn</i>() when either FD_CLOEXEC or FD_CLOFORK is set.</blockquote> On page 568 line 19882 section accept(), after the bug 411 text:<blockquote>SOCK_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on the new file descriptor.</blockquote></blockquote>add:<blockquote>SOCK_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on the new file descriptor.</blockquote></blockquote> On page 569 line 19914 section accept(), after applying bug 411 change:<blockquote>The SOCK_CLOEXEC flag of <i>accept4</i>() is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>accept</i>() and then using <i>fcntl</i>() to set the FD_CLOEXEC flag.</blockquote>to:<blockquote>The SOCK_CLOEXEC and SOCK_CLOFORK flags of <i>accept4</i>() are necessary to avoid a data race in multi-threaded applications. Without SOCK_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>accept</i>() and then using <i>fcntl</i>() to set the FD_CLOFORK flag. Without SOCK_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.</blockquote> On page 714 line 24432 section creat(), after applying bug 411 change:<blockquote>In multi-threaded applications, the <i>creat</i>() function can leak file descriptors into child processes. Applications should instead use <i>open</i>() with the O_CLOEXEC flag to avoid the leak.</blockquote>to:<blockquote>In multi-threaded applications, the <i>creat</i>() function can leak file descriptors into child processes. Applications should instead use <i>open</i>() with the O_CLOEXEC and O_CLOFORK flags to avoid the leak.</blockquote> On page 752 line 25609 section dup(), change:<blockquote>Upon successful completion, if <i>fildes</i> is not equal to <i>fildes2</i>, the FD_CLOEXEC flag associated with <i>fildes2</i> shall be cleared. If <i>fildes</i> is equal to <i>fildes2</i>, the FD_CLOEXEC flag associated with <i>fildes2</i> shall not be changed.</blockquote>to:<blockquote>Upon successful completion, if <i>fildes</i> is not equal to <i>fildes2</i>, the FD_CLOEXEC and FD_CLOFORK flags associated with <i>fildes2</i> shall be cleared. If <i>fildes</i> is equal to <i>fildes2</i>, the FD_CLOEXEC and FD_CLOFORK flags associated with <i>fildes2</i> shall not be changed.</blockquote> On page 752 line 25612 section dup(), after applying bug 411 change:<blockquote>Additionally, the <i>flag</i> parameter can be set to O_CLOEXEC (from <b><fcntl.h></b>) to cause FD_CLOEXEC flag to be set on the new file descriptor.</blockquote>to:<blockquote>Additionally, the <i>flag</i> argument can be constructed from a bitwise-inclusive OR of flags (defined in <b><fcntl.h></b>) from the following list: O_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on <i>fildes2</i>.</blockquote> O_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on <i>fildes2</i>.</blockquote></blockquote> On page 753 line 25650 section dup(), change:<blockquote>In order to avoid a race condition of leaking an unintended file descriptor into a child process, an application should consider opening all file descriptors with the FD_CLOEXEC bit set unless the file descriptor is intended to be inherited across <i>exec</i>.</blockquote>to:<blockquote>In order to avoid a race condition of leaking an unintended file descriptor into a child process or executed program, an application should consider opening all file descriptors with the FD_CLOFORK or FD_CLOEXEC flag, or both flags, set unless the file descriptor is intended to be inherited by child processes or executed programs, respectively.</blockquote> On page 753 line 25664 section dup(), after applying bug 411 change:<blockquote>The <i>dup3</i>() function with the O_CLOEXEC flag is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>dup2</i>() and then using <i>fcntl</i>() to set the FD_CLOEXEC flag. The safe counterpart for avoiding the same race in <i>dup</i>() is the use of the F_DUP_CLOEXEC action of the <i>fcntl</i>() function.</blockquote>to:<blockquote>The <i>dup3</i>() function with the O_CLOEXEC and O_CLOFORK flags is necessary to avoid a data race in multi-threaded applications. Without O_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>dup2</i>() and then using <i>fcntl</i>() to set the FD_CLOFORK flag. Without O_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically. The safe counterpart for avoiding the same race with <i>dup</i>() is the use of the F_DUPFD_CLOFORK or F_DUPFD_CLOEXEC action of the <i>fcntl</i>() function.</blockquote> On page 784 line 26576 section exec, change:<blockquote>For those file descriptors that remain open, all attributes of the open file description remain unchanged.</blockquote>to:<blockquote>For those file descriptors that remain open, all attributes of the open file description shall remain unchanged and the FD_CLOFORK file descriptor flag, if set, shall remain set.</blockquote> On page 820 line 27760 section fcntl(), change:<blockquote>The FD_CLOEXEC flag associated with the new file descriptor shall be cleared to keep the file open across calls to one of the exec functions.</blockquote>to:<blockquote>The FD_CLOEXEC and FD_CLOFORK flags associated with the new file descriptor shall be cleared.</blockquote> On page 820 line 27765 section fcntl(), add:<blockquote>F_DUPFD_CLOFORK<blockquote>Like F_DUPFD, but the FD_CLOFORK flag associated with the new file descriptor shall be set.</blockquote></blockquote> On page 820 line 27771 section fcntl(), change:<blockquote>If the FD_CLOEXEC flag in the third argument is 0, the file descriptor shall remain open across the <i>exec</i> functions; otherwise, the file descriptor shall be closed upon successful execution of one of the <i>exec</i> functions.</blockquote>to:<blockquote>If the FD_CLOEXEC flag in the third argument is set, the file descriptor shall be closed upon successful execution of an <i>exec</i> family function [SPN]and in the new process image created by <i>posix_spawn</i>() or <i>posix_spawnp</i>()[/SPN]; otherwise, the file descriptor shall remain open. If the FD_CLOFORK flag in the third argument is set, the file descriptor shall not be inherited by any child process created from a process that has the file descriptor open; otherwise, the file descriptor shall be inherited.</blockquote> On page 823 line 27898 section fcntl(), add to RETURN VALUE:<blockquote>F_DUPFD_CLOFORK<blockquote>A new file descriptor.</blockquote></blockquote> On page 823 line 27923, 27928 section fcntl(), change:<blockquote>F_DUPFD or F_DUPFD_CLOEXEC</blockquote>to:<blockquote>F_DUPFD, F_DUPFD_CLOEXEC, or F_DUPFD_CLOFORK</blockquote> On page 825 line 28010 section fcntl(), add to APPLICATION USAGE:<blockquote>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. (The alternative of first using F_DUPFD_CLOEXEC and then setting FD_CLOFORK with F_SETFD has a timing window where another thread could create a child process which inherits the new descriptor because FD_CLOFORK has not yet been set.) The FD_CLOFORK flag takes effect for all child processes, not just those created using <i>fork</i>() or <i>_Fork</i>().</blockquote> On page 1319 line 43930 section mkdtemp(), after the bug 411 text:<blockquote>O_CLOEXEC Set the FD_CLOEXEC file descriptor flag.</blockquote>add:<blockquote>O_CLOFORK Set the FD_CLOFORK file descriptor flag.</blockquote> On page 1320 line 43980 section mkdtemp(), after applying bug 411 change:<blockquote>The function <i>mkostemp</i>() with the O_CLOEXEC flag is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a temporary file descriptor with <i>mkstemp</i>() and then using <i>fcntl</i>() to set the FD_CLOEXEC flag.</blockquote>to:<blockquote>The O_CLOEXEC and O_CLOFORK flags of <i>mkostemp</i>() are necessary to avoid a data race in multi-threaded applications. Without O_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a temporary file descriptor with <i>mkstemp</i>() and then using <i>fcntl</i>() to set the FD_CLOFORK flag. Without O_CLOEXEC, a temporary file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.</blockquote> On page 1408 line 46762 section open(), add:<blockquote>The FD_CLOFORK file descriptor flag associated with the new file descriptor shall be cleared unless the O_CLOFORK flag is set in <i>oflag</i>.</blockquote> On page 1408 line 46780 section open(), add:<blockquote>O_CLOFORK<blockquote>If set, the FD_CLOFORK flag for the new file descriptor shall be set.</blockquote></blockquote> On page 1408 line 47033 section open(), add:<blockquote>The O_CLOEXEC and O_CLOFORK flags of <i>open</i>() are necessary to avoid a data race in multi-threaded applications. Without O_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>open</i>() and then using <i>fcntl</i>() to set the FD_CLOFORK flag. Without O_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.</blockquote> On page 1430 line 47470 section pipe(), change:<blockquote>The O_NONBLOCK and FD_CLOEXEC flags shall be clear on both file descriptors. (The <i>fcntl</i>() function can be used to set both these flags.)</blockquote>to:<blockquote>The FD_CLOEXEC and FD_CLOFORK flags shall be clear on both file descriptors. The O_NONBLOCK flag shall be clear on both open file descriptions. (The <i>fcntl</i>() function can be used to set this flag.)</blockquote> On page 1430 line 47481 section pipe(), after the bug 411 text:<blockquote>O_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on both new file descriptors.</blockquote></blockquote>add:<blockquote>O_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on both new file descriptors.</blockquote></blockquote> On page 1431 line 47530 section pipe(), after applying bug 411 change:<blockquote>The O_CLOEXEC flag of <i>pipe2</i>() is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>pipe</i>() and then using <i>fcntl</i>() to set the FD_CLOEXEC flag. The O_NONBLOCK flag is for convenience in avoiding additional <i>fcntl</i>() calls.</blockquote>to:<blockquote>The O_CLOEXEC and O_CLOFORK flags of <i>pipe2</i>() are necessary to avoid a data race in multi-threaded applications. Without O_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>pipe</i>() and then using <i>fcntl</i>() to set the FD_CLOFORK flag. Without O_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically. Since pipes are often used for communication between a parent and child process, O_CLOFORK has to be used with care in order for the pipe to be usable. If the parent will be writing and the child will be reading, O_CLOFORK should be used when creating the pipe, and then <i>fcntl</i>() should be used to clear FD_CLOFORK for the read side of the pipe. This prevents the write side from leaking into other children, ensuring the child will get end-of-file when the parent closes the write side (although the read side can still be leaked). If the parent will be reading and the child will be writing, there is no way to prevent the write side being leaked (short of preventing other threads from creating child processes) in order to ensure the parent gets end-of-file when the child closes the write side, and so the two processes should use an alternative method of indicating the end of communications. Arranging for FD_CLOEXEC to be set appropriately is more straightforward. The parent should use O_CLOEXEC when creating the pipe and the child should clear FD_CLOEXEC on the side to be passed to the new program before calling an <i>exec</i> family function to execute it. The O_NONBLOCK flag is for convenience in avoiding additional <i>fcntl</i>() calls.</blockquote> On page 1437 line 47733 section popen(), after applying bug 411 change:<blockquote>The <i>popen</i>() function shall ensure that any streams from previous <i>popen</i>() calls that remain open in the parent process are closed in the new child process, regardless of the FD_CLOEXEC status of the file descriptor underlying those streams.</blockquote>to:<blockquote>The <i>popen</i>() function shall ensure that any streams from previous <i>popen</i>() calls that remain open in the parent process are closed in the new child process, regardless of the FD_CLOEXEC or FD_CLOFORK status of the file descriptor underlying those streams.</blockquote> On page 1437 line 47738 section popen(), after:<blockquote>... shall be the readable end of the pipe.</blockquote>add:<blockquote>The FD_CLOFORK flag shall be cleared on both the STDOUT_FILENO file descriptor passed to the child process and the file descriptor underlying the returned stream.</blockquote> On page 1437 line 47742 section popen(), after:<blockquote>... shall be the writable end of the pipe.</blockquote>add:<blockquote>The FD_CLOFORK flag shall be cleared on both the STDIN_FILENO file descriptor passed to the child process and the file descriptor underlying the returned stream.</blockquote> On page 1439 line 47807 section popen(), after the bug 411 text:<blockquote>... any application worried about the potential file descriptor leak will already be using the <i>e</i> modifier.</blockquote>add a new paragraph:<blockquote>Implementations are encouraged to add support for a "wf" mode which creates the pipe as if by calling <i>pipe2</i>() with the O_CLOFORK flag and then clearing FD_CLOFORK for the read side of the pipe. This prevents the write side from leaking into child processes created by other threads, ensuring the child created by <i>popen</i>() will get end-of-file when the parent closes the write side (although the read side can still be leaked). Unfortunately there is no way (short of temporarily preventing other threads from creating child processes, or implementing an atomic create-pipe-and-fork system call) to implement an "rf" mode with the equivalent guarantee that the child created by <i>popen</i>() will be the only writer. Therefore multi-threaded applications that do not have complete control over process creation cannot rely on getting end-of-file on the stream and need to use an alternative method of indicating the end of communications.</blockquote> On page 1450 line 48133 section posix_openpt(), after the bug 411 text:<blockquote>O_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on the file descriptor.</blockquote></blockquote>add:<blockquote>O_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on the file descriptor.</blockquote></blockquote> On page 1451 line 48179 section posix_openpt(), after applying bug 411 change:<blockquote>The function <i>posix_openpt</i>() with the O_CLOEXEC flag is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>posix_openpt</i>() and then using <i>fcntl</i>() to set the FD_CLOEXEC flag.</blockquote>to:<blockquote>The O_CLOEXEC and O_CLOFORK flags are necessary to avoid a data race in multi-threaded applications. Without O_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread creating a file descriptor with <i>posix_openpt</i>() and then using <i>fcntl</i>() to set the FD_CLOFORK flag. Without O_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.</blockquote> On page 1452 line 48235 section posix_spawn(), change:<blockquote>If <i>file_actions</i> is a null pointer, then file descriptors open in the calling process shall remain open in the child process, except for those whose close-on-<i>exec</i> flag FD_CLOEXEC is set (see <i>fcntl</i>()).</blockquote>to:<blockquote>If <i>file_actions</i> is a null pointer, then file descriptors open in the calling process shall remain open in the child process, except for those whose FD_CLOEXEC or FD_CLOFORK flag is set (see <i>fcntl</i>()), and except for file descriptors that are closed by a fork handler (if fork handlers are called).</blockquote> On page 1452 line 48240 section posix_spawn(), change:<blockquote>If <i>file_actions</i> is not NULL, then the file descriptors open in the child process shall be those open in the calling process as modified by the spawn file actions object pointed to by <i>file_actions</i> and the FD_CLOEXEC flag of each remaining open file descriptor after the spawn file actions have been processed. The effective order of processing the spawn file actions shall be:<ol><li>The set of open file descriptors for the child process shall initially be the same set as is open for the calling process. The child process shall not inherit any file locks, but all remaining attributes of the corresponding open file descriptions (see <i>fcntl</i>()), shall remain unchanged.</li> <li>The signal mask, signal default actions, and the effective user and group IDs for the child process shall be changed as specified in the attributes object referenced by <i>attrp</i>.</li> <li>The file actions specified by the spawn file actions object shall be performed in the order in which they were added to the spawn file actions object.</li> <li>Any file descriptor that has its FD_CLOEXEC flag set (see <i>fcntl</i>()) shall be closed.</li> </ol></blockquote>to:<blockquote>If <i>file_actions</i> is not a null pointer, then the file descriptors open in the child process shall be those open in the calling process as modified by FD_CLOFORK file descriptor flags, fork handlers (if they are called), the spawn file actions object pointed to by <i>file_actions</i>, and the FD_CLOEXEC of each remaining open file descriptor after the spawn file actions have been processed. The effective order of processing the spawn file actions shall be:<ol><li>The set of open file descriptors for the child process shall initially be the same set as is open for the calling process, except for those that have the FD_CLOFORK flag set and any that are closed by fork handlers (if they are called).</li> <li>The child process shall not inherit any file locks, but all remaining attributes of the corresponding file descriptions (see <i>fcntl</i>()) still open, shall remain unchanged.</li> (Note: moved to separate list item as lock clearing applies to files left open after close only, as a separate from closing before applying file actions object.) <li>The signal mask, signal default actions, and the effective user and group IDs for the child process shall be changed as specified in the attributes object referenced by <i>attrp</i>.</li> <li>The file actions specified by the spawn file actions object shall be performed in the order in which they were added to the spawn file actions object.</li> <li>Any file descriptor that has its FD_CLOEXEC flag set shall be closed.</li> </ol></blockquote> On page 1456 line 48397 section posix_spawn(), change:<blockquote>... expressed as the set of open file descriptors and their FD_CLOEXEC flags at the time of the call and the spawn file actions object specified in the call.</blockquote>to:<blockquote>... expressed as the set of open file descriptors and their FD_CLOEXEC and FD_CLOFORK flags at the time of the call, the actions of fork handlers (if they are called), and the spawn file actions object specified in the call.</blockquote> On page 1461 line 48592 section posix_spawn_file_actions_addclose(), and On page 1463 line 48702 section posix_spawn_file_actions_adddup2(), change:<blockquote>In order to avoid a race condition of leaking an unintended file descriptor into a child process, an application should consider opening all file descriptors with the FD_CLOEXEC bit set unless the file descriptor is intended to be inherited across <i>exec</i>.</blockquote>to:<blockquote>In order to avoid a race condition of leaking an unintended file descriptor into a child process or executed program, an application should consider opening all file descriptors with the FD_CLOFORK or FD_CLOEXEC flag, or both flags, set unless the file descriptor is intended to be inherited by child processes or executed programs, respectively.</blockquote> On page 1546 line 50637 section posix_typed_mem_open(), after the bug 411 text:<blockquote>The FD_CLOEXEC file descriptor flag associated with the new file descriptor shall be cleared unless <i>oflag</i> includes O_CLOEXEC.</blockquote>add:<blockquote>The FD_CLOFORK file descriptor flag associated with the new file descriptor shall be cleared unless <i>oflag</i> includes O_CLOFORK.</blockquote> On page 1546 line 50647 section posix_typed_mem_open(), after applying bug 411 change:<blockquote>Additionally, the value of <i>oflag</i> may include the following flag: O_CLOEXEC Set the FD_CLOEXEC file descriptor flag.</blockquote>to:<blockquote>Additionally, the value of <i>oflag</i> may include the following flags: O_CLOEXEC Set the FD_CLOEXEC file descriptor flag. O_CLOFORK Set the FD_CLOFORK file descriptor flag.</blockquote> On page 1547 line 50678 section posix_typed_mem_open(), after applying bug 411 change:<blockquote>The use of the O_CLOEXEC flag to <i>posix_typed_mem_open</i>() is necessary to avoid leaking typed memory file descriptors to child processes, since <i>fcntl</i>() has unspecified results on typed memory objects and therefore cannot be used to set FD_CLOEXEC after the fact.</blockquote>to:<blockquote>The use of the O_CLOEXEC and O_CLOFORK flags to <i>posix_typed_mem_open</i>() is necessary to avoid leaking typed memory file descriptors to child processes, since <i>fcntl</i>() has unspecified results on typed memory objects and therefore cannot be used to set FD_CLOEXEC or FD_CLOFORK after the file descriptor has been opened.</blockquote> On page 1799 line 58230 section recvmsg(), after the bug 411 text:<blockquote>MSG_CMSG_CLOEXEC<blockquote>On sockets that permit a cmsg_type of SCM_RIGHTS in the msg_control ancillary data as a means of copying file descriptors into the process, the file descriptors shall be created with the FD_CLOEXEC flag atomically set.</blockquote></blockquote>add:<blockquote>MSG_CMSG_CLOFORK<blockquote>On sockets that permit a cmsg_type of SCM_RIGHTS in the msg_control ancillary data as a means of copying file descriptors into the process, the file descriptors shall be created with the FD_CLOFORK flag atomically set.</blockquote></blockquote> On page 1801 line 58306 section recvmsg(), after applying bug 411 change:<blockquote>The use of the MSG_CMSG_CLOEXEC flag to <i>recvmsg</i>() when using SCM_RIGHTS to receive file descriptors via ancillary data is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread calling <i>recvmsg</i>() and using <i>fcntl</i>() to set the FD_CLOEXEC flag.</blockquote>to:<blockquote>The use of the MSG_CMSG_CLOEXEC and MSG_CMSG_CLOFORK flags to <i>recvmsg</i>() when using SCM_RIGHTS to receive file descriptors via ancillary data is necessary to avoid a data race in multi-threaded applications. Without MSG_CMSG_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread calling <i>recvmsg</i>() and using <i>fcntl</i>() to set the FD_CLOFORK flag. Without MSG_CMSG_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.</blockquote> On page 2004 line 64479 section socket(), after the bug 411 text:<blockquote>SOCK_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on the new file descriptor.</blockquote></blockquote>add:<blockquote>SOCK_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on the new file descriptor.</blockquote></blockquote> On page 2005 line 64511 section socket(), after applying bug 411 change:<blockquote>The use of the SOCK_CLOEXEC flag in the <i>type</i> argument of <i>socket</i>() is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread calling <i>socket</i>() and using <i>fcntl</i>() to set the FD_CLOEXEC flag.</blockquote>to:<blockquote>The use of the SOCK_CLOEXEC and SOCK_CLOFORK flags in the <i>type</i> argument of <i>socket</i>() is necessary to avoid a data race in multi-threaded applications. Without SOCK_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another thread calling <i>socket</i>() and using <i>fcntl</i>() to set the FD_CLOFORK flag. Without SOCK_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.</blockquote> On page 2006 line 64553 section socketpair(), after the bug 411 text:<blockquote>SOCK_CLOEXEC<blockquote>Atomically set the FD_CLOEXEC flag on the new file descriptors.</blockquote></blockquote>add:<blockquote>SOCK_CLOFORK<blockquote>Atomically set the FD_CLOFORK flag on the new file descriptors.</blockquote></blockquote> On page 2007 line 64588 section socketpair(), after applying bug 411 change:<blockquote>The use of the SOCK_CLOEXEC flag in the <i>type</i> argument of <i>socketpair</i>() is necessary to avoid a data race in multi-threaded applications. Without it, a file descriptor is leaked into a child process created by one thread in the window between another thread using <i>socketpair</i>() and using <i>fcntl</i>() to set the FD_CLOEXEC flag. The SOCK_NONBLOCK flag is for convenience in avoiding additional <i>fcntl</i>() calls.</blockquote>to:<blockquote>The use of the SOCK_CLOEXEC and SOCK_CLOFORK flags in the <i>type</i> argument of <i>socketpair</i>() is necessary to avoid a data race in multi-threaded applications. Without SOCK_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another using <i>socketpair</i>() and using using <i>fcntl</i>() to set the FD_CLOFORK flag. Without SOCK_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically. Since socket pairs are often used for communication between a parent and child process, SOCK_CLOFORK has to be used with care in order for the pair to be usable. If the parent will be writing and the child will be reading, SOCK_CLOFORK should be used when creating the pair, and then <i>fcntl</i>() should be used to clear FD_CLOFORK for the read side of the pair. This prevents the write side from leaking into other children, ensuring the child will get end-of-file when the parent closes the write side (although the read side can still be leaked). If the parent will be reading and the child will be writing, or if the socket pair will be used bidirectionally, there is no way to prevent the write side(s) being leaked (short of preventing other threads from creating child processes) in order to ensure the parent gets end-of-file when the child closes its side, and so the two processes should use an alternative method of indicating the end of communications, for example using <i>shutdown</i>(). Arranging for FD_CLOEXEC to be set appropriately is more straightforward. The parent should use SOCK_CLOEXEC when creating the socket pair and the child should clear FD_CLOEXEC on the side to be passed to the new program before calling an <i>exec</i> family function to execute it. The SOCK_NONBLOCK flag is for convenience in avoiding additional <i>fcntl</i>() calls.</blockquote> On page 2108 line 67621 section system(), change:<blockquote>For example, file descriptors that have the FD_CLOEXEC flag set are closed, and ...</blockquote>to:<blockquote>For example, file descriptors that have the FD_CLOEXEC or FD_CLOFORK flag set are closed, and ...</blockquote> On page 2163 line 69329 section tmpfile(), after applying bug 411 change:<blockquote>Applications should instead use <i>mkostemp</i>() with the O_CLOEXEC flag, followed by <i>fdopen</i>(), to avoid the leak.</blockquote>to:<blockquote>Applications should instead use <i>mkostemp</i>() with the O_CLOEXEC or O_CLOFORK flag, or both, followed by <i>fdopen</i>(), to avoid the leak.</blockquote> 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 2020-03-05 17:30 eblake Relationship added related to 0001317 2020-03-16 16:24 geoffclare Note Added: 0004797 ======================================================================
