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.


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.


Philip Guenther
  • [1003.1(20... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
      • R... Steffen Nurpmeso via austin-group-l at The Open Group
        • ... Philip Guenther via austin-group-l at The Open Group
          • ... Steffen Nurpmeso via austin-group-l at The Open Group
            • ... Philip Guenther via austin-group-l at The Open Group
              • ... enh via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to