[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZsmlM89E75HYuhTv@voyager>
Date: Sat, 24 Aug 2024 11:17:39 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: fcntl: Purpose of second DUPFD_CLOEXEC?
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
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.
