From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id EB8162AC0C for ; Sat, 24 Aug 2024 11:17:54 +0200 (CEST) Received: (qmail 31961 invoked by uid 550); 24 Aug 2024 09:17:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31926 invoked from network); 24 Aug 2024 09:17:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1724491061; x=1725095861; i=nullplan@gmx.net; bh=BpzmOF0gMACuoxiBNryUU7WRzo8hS4enwniPUfFxp4o=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To:Content-Transfer-Encoding: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=pchrQ5HbE121Ls1MM4wLoEg9vA9JDDkqsd8fgvIiDVeXjhfw+pkmLIVkIkxeuh2/ pmbpmA4pnHi3PdLzpe75HZ5zvnsrLpjZZ2Bg5ALosTQPtGT3MjtDQZ9bCY63sK6cB cOrXKWo+VUAdmHgfayZ6Je8yKCCEOJ2eXyXwCmgcTPYPqGwNJreGi4dpcPKQvlkWf aKQ+cyC65LSP3AmPQDvAKDcL1Iq2aJ4eftnU9Q5Bg9ckrk8aR9jfzCz4pzclJ2V2D yncpygJpyj0lZMg8Hp3FqR01oCjcTAsxChyyDvAobu5YVVnvzBp+9DNcfQnnfBupU F/fRq0i+1Czz7wY3jQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sat, 24 Aug 2024 11:17:39 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <20240822144852.GA10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240822144852.GA10433@brightrain.aerifal.cx> X-Provags-ID: V03:K1:ivx3F/WkB5BeyP4+CCo9JHV6Vm7hFGrZwOBwUXcpBsrG3JyNmp/ MX6zHCr8cg7SPNIMKQJz37d63foKokVNYtH3XIVfNFGYIqMj9wdw8tCAsNYEDkjMphTdL1Z bryjgL45upH4BKQvuuQK41dw5lNe2Zu+v4T3+PWTGBxKYzhDCixZyAFSWWOVAAwzsbqiq4M x2KS+RLlVz12acWOHCtpw== UI-OutboundReport: notjunk:1;M01:P0:nHFsPBGEbf4=;NY4tAz2uyMO9QzhrlmRYkW2f3LD kJ9XgjLf6MBe3qt0aH+unrvGWTJ0ZdcbJWzHiZ4Lst7aas54ZGWprk/HMLRqOl5+8H8kNhu1v bHZIRlS9qCfF9hZ+tq43EOlOiFrrjAmktSBeNakKghtT3MNq4zOJqELddZGURwy47z21Odem7 OBiQzDq05UE+phzwNk6EtjoXM9VCEqxBxSyrh69RSr03TZUefHoTCfknWeT8x+TBnNLpjEDNq T1f8zH3S7rnYbEUyOj4G3w+3U9pcVPnRteQ/wKzmotnDDwA2bUX16jHJpjV3l0p5dUowr1eaW Qi4SGZSK9abF4KaekbhpT7xZPiQFWB6Im/6rcpWxp72JgxuARHGehW72PrAHdwaOInIy11P/g Ux2KOI6htfN9NGTZTjCap3cv5btWbGUTPMvXVQ4Q7f+b9EGX42Tst8ESXQOHOQu7piSalfvT7 IdQdb3i6+LWDLtvLU5rpAHD16TupnW8X5DIO5mbCpXOV0PrkWMaDctbvCUWRNbWP/tgsLMrOV E0lWKkNewt+MuNu/rdE/Pw+Q8Hc6K0aLZ46Xf63rl0uh13+6X3VXUFDokOVgbt9cMAhKWDauv XyPpb02q4poF38RzRGPuvBHeNr9WLMSd6gd6hjQ06Jk7bKbhSsioLGckA2C+GNsqZjwZ+rUTj tVzISRnGzaWDU8TTbfgM36Su70sDSq40REpyLjTgT9BIFiP+upUtCwgDPEbg1Q4q+XSd2t4wZ OsSf6HG+GPtPSqzrX0qncevIYlVmPcxUqH6W/iqq9hc4+f6RfpyAoIYF/LF8S/ubdckcNg9yy w8GVF8Z8aPDoFeH+QxtYnfPA== Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] 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. =46rom 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