So I've been looking at implementing close-on-fork support for OpenBSD and I'm wondering what existing implementation experience exists for this in a secure, mutli-user implementation.
I know that, for example, per https://sortix.org/blog/posix-2024/ Sortix has implemented close-on-fork since 2013, but it disclaims being "secure for multi-user uses" on that same page. My concern so far centers on the requirement that the FD_CLOFORK flag be preserved across exec. 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. So, who has already implemented the behavior as specified and what security analyses and/or experiences have they had? As is and lacking better justification for preserving the flag across exec and how that's not going to cause issues for existing programs, there's no chance right now that OpenBSD will implement this with the flag preserved across _any_ exec, whether setuid, setgid, or neither. Philip Guenther ** 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
