![]() |
|
Message-ID: <b29cd279-27ee-4569-a5b5-16e9d40bd3c2@gmail.com> Date: Fri, 19 Sep 2025 20:38:22 -0400 From: Demi Marie Obenour <demiobenour@...il.com> To: musl@...ts.openwall.com, Laurent Bercot <ska-dietlibc@...rnet.org> Subject: Re: closefrom and close_range wrappers On 9/13/25 04:43, Laurent Bercot wrote: >> Would it make sense for musl to provide close_range and >> closefrom? The main uses of them are to close unwanted >> FDs after a fork and before exec. close_range() can also >> be used to mark them close-on-exec instead. > > Using these functions is always a programming error. Programs > should never (with very few exceptions, and the use case [generic-]you > are thinking about is probably not one of them, and yes, lots of > shells are broken in that aspect) close file descriptors they do > not own. > > It is an entirely valid programming practice for a parent to leak a > descriptor into an unknowing child, for various reasons, one of which > (the most obvious, but not the only one) being detection of said > child's death by an unrelated process. Closing unknown fds prevents > this and breaks existing, valid setups. I actually found a case where it is *necessary* to close unknown fds for correctness. Consider a wrapper program that runs a child process and waits for it to exit. In this case, it is necessary to pass unknown fds into the child process, but they *must* be closed in the parent process! Otherwise, the file descriptors would be kept open even after the child process had closed them, which is wrong. For instance, code reading a pipe will not get EOF as long as the parent process has it open. Process supervision is not affected because the parent process doesn't do anything significant, so it is okay to consider the service finished as long as the child process is dead. The parent will exit soon afterwards anyway. Yes, this is undefined behavior on implementations that rely on some FDs to be open, but to the best of my knowledge musl, glibc, and the BSDs all do not need this. -- Sincerely, Demi Marie Obenour (she/her/hers) Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes) Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.