[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ddc19c20-caa7-44a7-8f11-60fb0856bd2f@gmail.com>
Date: Sat, 13 Sep 2025 17:19:35 -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 think the current reality is that too much stuff in the wild closes
unknown FDs for this to be reliable. On Linux, the same can be done
in far more robust ways with prctl(PR_SET_SUBREAPER) or cgroups.
Solaris and illumos have their contract system used by SMF, and the
BSDs don't have any robust system I know of.
>> The main advantage of closefrom() is that it is portable
>> to more systems. Closing file descriptors one doesn't own
>> is not an issue because the code that does own these FDs
>> will never get a chance to run.
>
> That is very much an issue. The code that does own these fds is
> likely not in the same process, and is running.
>
>
>> Yes, this is all a consequence of fork()/exec() being an
>> extremely poor API, but I don't know of a better solution.
>
> Every piece of code that opens a descriptor should track it, just
> like any other resource. If the code wants to leave the cleanup to
> the kernel, that's what O_CLOEXEC is for. None of this is new.
There are too many broken third-party libraries for this to be
feasible in general. Without closefrom or close_range, programs
*will* iterate over /proc/self/fd to get the same result.
--
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.
