Re: [musl] fcntl: Purpose of second DUPFD_CLOEXEC?

[Markus Wichmann <nullplan@gmx.net>]

Am Thu, Aug 22, 2024 at 10:48:53AM -0400 schrieb Rich Felker:
> That's a good point -- F_DUPFD can be expected to fail (thus not
> introduce any fd leak race condition) as long as the limit does not
> change concurrently with the fcntl call. But if the limit does change
> concurrently, the test result may be outdated by the time it's used.
> So I think it may make sense to try the fallback directly.
>

If the limit is lowered concurrently, then the DUPFD either comes in
before that and everything works out, or all calls return -EINVAL. If
the limit is raised concurrently, then in both versions of this, there
are timings where musl spuriously allocates a non-CLOEXEC file
descriptor for a short time (as in, the kernel could have given us a
CLOEXEC FD from the start). I don't think you can win in this. But in
the original version, there are also timings where you allocate an FD,
close it, and return EINVAL.

From the point of view of the caller, calling fcntl(F_DUPFD_CLOEXEC)
while simultaneously changing the FD limit results in either an EINVAL
return or a file descriptor with CLOEXEC flag. And that happens also in
both versions.

Ciao,
Markus