View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001851 | 1003.1(2024)/Issue8 | System Interfaces | public | 2024-08-11 02:11 | 2025-06-30 17:05 |
| Reporter | philip-guenther | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | New | Resolution | Open | ||
| Name | Philip Guenther | ||||
| Organization | OpenBSD | ||||
| User Reference | |||||
| Section | exec | ||||
| Page Number | 867 | ||||
| Line Number | 29528-29530 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001851: 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. | ||||
| Tags | No tags attached. | ||||
| related to | 0001318 | Closed | 1003.1(2016/18)/Issue7+TC2 | Define close-on-fork flag |
|
|
More than ten months and no word or concern from other implementations? Weird. OpenBSD will probably go ahead and implement close-on-fork but forcibly clearing the flag on exec. |
|
|
This was just raised in the illumos community, as well. It would be very useful to address. Thanks! |
|
|
Sorry, we discussed thus internally, but failed to update the bug here with our decision. Solaris initially implemented O_CLOFORK in the Solaris 11.3.0 release, and did no special handling across exec (as far as I can see the issue wasn't considered at the time). Given the discussion initiated here, we have modified our implementation to clear the O_CLOFORK flag on exec starting in Solaris 11.4.78. |
|
|
FYI, illumos has made a change to implement the same behavior as Solaris. https://github.com/illumos/illumos-gate/commit/b3ff81dc6673bee7f291d9d66a832cb3e1004f49 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-08-11 02:11 | philip-guenther | New Issue | |
| 2024-08-11 02:11 | philip-guenther | Name | => Philip Guenther |
| 2024-08-11 02:11 | philip-guenther | Organization | => OpenBSD |
| 2024-08-11 02:11 | philip-guenther | Section | => exec |
| 2024-08-11 02:11 | philip-guenther | Page Number | => 867 |
| 2024-08-11 02:11 | philip-guenther | Line Number | => 29528-29530 |
| 2024-08-15 15:39 | geoffclare | Relationship added | related to 0001318 |
| 2025-06-21 23:47 | philip-guenther | Note Added: 0007206 | |
| 2025-06-23 13:51 | dancross | Note Added: 0007208 | |
| 2025-06-23 20:54 | alanc | Note Added: 0007209 | |
| 2025-06-30 17:05 | dancross | Note Added: 0007218 |
