Hello Philip. Philip Guenther wrote in <CAKKmsNhNfDt9cpJz-Wor5VGFrQ99=bd-s8fn_cfiescg67z...@mail.gmail.com>: |On Monday, June 23, 2025, Steffen Nurpmeso via austin-group-l at The Open |Group <[email protected]> wrote: |> Austin Group Issue Tracker via austin-group-l at The Open Group wrote in |> <[email protected]>: |>|A NOTE has been added to this issue. |>|====================================================================== |>|https://austingroupbugs.net/view.php?id=1851 |>|====================================================================== |>|Reported By: philip-guenther |> ... |>|Summary: FD_CLOFORK should not be preserved across |> exec |> ... |>| (0007206) philip-guenther (reporter) - 2025-06-21 23:47 |>| https://austingroupbugs.net/view.php?id=1851#c7206 |>|---------------------------------------------------------------------- |>|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. |> |> Only for the (rare) idiots among the listeners, this refers to |> file descriptors open(2)ed etc after a fork(2), but before the |> execve(2), which are configured with CLOFORK? | | It’s about all file descriptors that have FD_CLOFORK set after fork but |before execve.
Yes, stupid me. Maybe i meant "why did it not imply CLOEXEC". If you read fcntl(2) 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 bee but even more the lengthy setup necessary for pipe(2)s 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 fcntl( ) 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 exec family function to execute it. The O_NONBLOCK flag is for convenience in avoiding additional fcntl( ) calls. Who has anything CLOFORK implemented as standardized already? musl has not, glibc not in at least my variant, the BSDs do not either. |If so, isn't this is very explicit configuration which' existence |> is possibly even desirable? | |I could find *zero* evidence that this was discussed when the functionally |was designed and, as I state in the bug: |* it is not required to solve the problem statement |* it creates potentially dangerous behavior in programs that may have no |way to prevent it (eg, anything released before this dev of the standard) | |If it was desired, it was not discussed or even suggested, but it certainly |looks undesirable to me and the other OpenBSD developers. Sure. |Philip Guenther --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear
