The following issue has been SUBMITTED. ====================================================================== https://www.austingroupbugs.net/view.php?id=1851 ====================================================================== Reported By: philip-guenther Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1851 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Philip Guenther Organization: OpenBSD User Reference: Section: exec Page Number: 867 Line Number: 29528-29530 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-08-11 02:11 UTC Last Modified: 2024-08-11 02:11 UTC ====================================================================== Summary: FD_CLOFORK should not be preserved across exec Description: Given the documented use-cases and rationale for close-on-fork in addressing a race condition in multi-threaded processes that mix fork() and file-descriptor creation, the need for the flag to be set would appear to end at the time of a successful exec, when all the other threads in the process are terminated. Since the appropriateness of the flag is specific to the internal design of a program, it seems it should be limited to the program that set it and be cleared by exec.
Having it set when not expected is going to cause program misbehavior. For example, a utility which calls fork() and then opens a file descriptor in the child will probably have unexpected behavior if it's invoked with FD_CLOFORK set on any of fds 0, 1, or 2 as stdin, stdout, or stderr ends up associated with an expected file/socket/whatever. Considering POSIX's evolution on the state of fds 0, 1, and 2 after exec**, reintroducing this issue for programs that fork seems like a regression. This is obviously even more concerning in the context of setuid/setgid programs. As an additional argument, consider that since the standard doesn't say that invoking a standard utility with FD_CLOFORK set on any the fds that the utility may use is an non-compliant invocation environment (like how completely clearing the environment is), compliant implementations of standard utilities must work as specified in that case. For utilities that fork and use inheritied-fds in the child, this renders implementations that were compliant on an Issue 7 system non-compliant on an Issue 8 system if they would have to clear FD_CLOFORK to operate correctly. The question of whether FD_CLOFORK should be preserved across exec appears to have been a lacuna in the original request, simply unconsidered there. While the specified behavior is simple to explain and implement, discussions with other OpenBSD systems programmers about what will need to change in the system when FD_CLOFORK is implemented has convinced us that it's unnecessary for the described goal, error prone, and will almost certainly result in security issues in existing programs if implemented as specified. ** Issue 5 and earlier: nothing special permitted. Issue 6: if 0, 1, or 2 would be closed after exec of setuid or setgid program, the system may open something on the would-be-closed fds. Issue 7: like issue 6, but for all programs, not just setuid/setgid ones Desired Action: Replace this sentence: 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. With something equivalent to: For those file descriptors that remain open, all attributes of the open file description shall remain unchanged except that the FD_CLOFORK file descriptor flag, if set, shall be cleared. If it cannot be changed in one jump in a TC, then at least render it unspecified whether FD_CLOFORK is preserved by exec, and if at all possible also require it to be cleared when a setuid/setgid program is invoked. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2024-08-11 02:11 philip-guentherNew Issue 2024-08-11 02:11 philip-guentherName => Philip Guenther 2024-08-11 02:11 philip-guentherOrganization => OpenBSD 2024-08-11 02:11 philip-guentherSection => exec 2024-08-11 02:11 philip-guentherPage Number => 867 2024-08-11 02:11 philip-guentherLine Number => 29528-29530 ======================================================================
