From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15567 invoked from network); 4 Aug 2022 13:44:38 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2022 13:44:38 -0000 Received: (qmail 18268 invoked by uid 550); 4 Aug 2022 13:44:35 -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 1343 invoked from network); 4 Aug 2022 12:43:12 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=Q9JlE1vBkquvbiIYYmRZgaqGZzXJH9z6IMWz6f8O9m8=; b=6HnAdYMTXK03y6jYVfruF1zDKs/Kb9SM59TSc0Q8HvRcHnwWyRWVNT7iguZyI7HR45 zIjs74WuK4yYXAJok1i8j+hES9Sa2k2cyESebVGH1jQ3CdgKaJTeKYtJBCfHpXFlbh5y tLaVagISvS28SVP4kIkXegdUofGKOtSOjJWJHNoJMtPE7kY1PcmPioCb9WMJCnGJ68ir CO92pnbUE4NoTWK6XP8+cCdxzvemhAB7YfD6Qef23qUu3SV7IvJK+vtyIRRwnPjomkz0 tRZ23MLfq7BY1eUMNWPaxG7bQ0Wugl5mOZXd+tjtPWcMO6ef/G6Y1QNy1Ka/fgVAjMIk Ai/g== X-Gm-Message-State: ACgBeo13DFzLGfGnzLHtLVvGMsA9DUufj/n/B8punzuTWo9Gn4OZmeBc lJ0iX2PKI1820DK5GEKQoqTkqvojZ4Z4MO8VqwL0EMQrpqg= X-Google-Smtp-Source: AA6agR5V+nNY47AMPxkQgDEy+cRsvw4Xk01rKl8pDFrOEyV5pHNYi3Gb6R6JGKg6N8EYKw2xqOP5inEggapLYnIbc3I= X-Received: by 2002:a17:902:a604:b0:16d:9bde:8657 with SMTP id u4-20020a170902a60400b0016d9bde8657mr1754697plq.17.1659616980250; Thu, 04 Aug 2022 05:43:00 -0700 (PDT) MIME-Version: 1.0 From: Sascha Brawer Date: Thu, 4 Aug 2022 14:42:49 +0200 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000092348a05e569b03e" Subject: [musl] Should fdopen() check the passed file descriptor? --00000000000092348a05e569b03e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear list Should musl=E2=80=99s fdopen() verify whether the passed file descriptor re= fers to an open file? glibc seems to do that, whereas musl doesn=E2=80=99t. According to the spec, fdopen "may" fail with EBADF if a bad file descriptor is passed. https://pubs.opengroup.org/onlinepubs/009696899/functions/fdopen.html I just ran into this difference while porting some user library (libosmium, for OpenStreetMap) to Alpine Linux which uses musl. For now I=E2=80=99m pat= ching the user library so it tests for fcntl(fd, F_GETFD) < 0 before invoking fdopen(). But I wonder if this check shouldn=E2=80=99t rather be done withi= n musl itself. What do you think? Thanks for cc=E2=80=99ing me on your thoughts, I=E2=80=99m not subscribed t= o the musl mailing list. Best, =E2=80=94 Sascha Brawer, sascha@brawer.ch --00000000000092348a05e569b03e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear list

Should musl=E2=80=99s=C2=A0fd= open() verify whether the passed file descriptor refers to an open file? gl= ibc seems to do that, whereas musl doesn=E2=80=99t.

According to the spec,=C2=A0fdopen "may" fail with EBADF if a b= ad file descriptor is passed.

= I just ran into this difference while porting some user library (libosmium,= for OpenStreetMap) to Alpine Linux which uses musl. For now I=E2=80=99m pa= tching the user library so it tests for fcntl(fd, F_GETFD) < 0 before in= voking fdopen(). But I wonder if this check shouldn=E2=80=99t rather be don= e within musl itself. What=C2=A0do you think?

Than= ks for cc=E2=80=99ing me on your thoughts, I=E2=80=99m not subscribed=C2=A0= to the musl mailing list. Best,

=E2=80=94 Sascha B= rawer, sascha@brawer.ch
<= br>


--00000000000092348a05e569b03e-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20648 invoked from network); 4 Aug 2022 14:23:31 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2022 14:23:31 -0000 Received: (qmail 11610 invoked by uid 550); 4 Aug 2022 14:23:29 -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 11575 invoked from network); 4 Aug 2022 14:23:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1659622995; bh=wCJbMGNiKG+FQWn0q3hz5Uz7Yyvp8OX4Ws0imr8OASE=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=cxcu1lmv4EeMP/aX3r0q/rnfI/+VKwCSWoItTvoK7jKeBG9tIFK7EqB9LLoSPmOqG rp0zFxlPoHVhnr7LsUOmtIeglcSiPKCBUN9kw2Vfk9L3QONlBhDplQY6r5Gau4WSl9 qMWBLR+bImLOAbS8GlGW5NqwqSPtky9pRL98DJBw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Thu, 4 Aug 2022 16:23:22 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Sascha Brawer Message-ID: <20220804142322.GC3042@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:GVWnwDfNKyWRkZnVq7s6xzUZ3N6nYNsT+Fb5Sfxh4qSQMfN8zJf VjpevwALU1PVY6wuRPup9hDqtqots1+4Ia1Lwny0ulGGjnof8AoxzBebtRx5Kpltv/4aR6s vtrOebsKeAjlIcAT0uiMGajOtQGYFoAhviy5ssUld5AveP5O1XClbMOS5LY3z7uxgXo1q+H GxRkZlAuhkQqplFjn4QYA== X-UI-Out-Filterresults: notjunk:1;V03:K0:clqrCcIRvU4=:M44OLWpjuafLWRTF00o5/3 zZKB+vaOeYrrYue8TqK+JRo3hGn1rRNQS2pz79eoAdadr7elvaHZubDl5NNkM26Xgg72ChXQ7 IMVli8Fx8T0SyL44VmIVoSVqxO3pdQmzgCjjwsT8DHHJu3xKRf9KFKdFbM4My6jAqXqOIT+s6 t0qEb6gUvk7m4+7WvBDMarOQ+EX//t+Lcx2pLxS/EGqEQXCoha4816IYZf7f6bsPwo7nlAqlN pB3n6wVvNlTg+7XigBGYN1C9jOpFE+fcZo+1Zz+BltW1Vm/KLg+xQFBTtePsqjLID0EY030dS 5vWyML5QicHGs6IBKnzow2YbcCgL9kWkPJ3spnJxFTeGKBiuUf1OyH8PxhJCDW2mMZNBckSdb Vl573Jx8YYfLDGOcGKFfQaEoJo08RmDxlo40MW5qMNqJJzkViP2TNS4/0WRkeebcANTdtAgyE nqyIdn49+iZ52WC7yiuFxeP8SrwTKB+nFIAjWe97GS7tAMf4RBG28akmVosrj/y9LfYyrXtSC c3DGqVn5Kg1JVj2QufFy3PWwAFyjZmX8BHOf/MTOeBM0zzXrsuLtGNT8ktkDWNaiMcWb0FLh3 zQakmFk7WfzQ0iDWZRmEXuYdO0Q7gXMmb97WfwGF65VyuT22eCC0DfPHhh0mMfk9l8qYZESJw YG6QDv/jHcxPT1qAe8fuihb9wH6idVEheZHe1CQ/vPxuupg9cds2FHt796Vnc0T/YUs+Oj62M yKenuLTBuoCsTlCqhgmLod1remGUq9zNXS/noLeyDgLhF1Td2QuV6aI2TihuYL83jvw+Cyttq 3SfucG/kOPz1DcV2jvcRbTNxvusfz/NSTgmH65y/k8gGf+lbv391FLOHVeI+Rzr37nacf1Z8m Ev4WAoohkg8RtVZsLMATl5RbTAaLMtUZRsnnzzSIJyB17hNzaZW0rHouYmw40A/7R98Kjl5U/ ldyj5d6cv5zIqjpfKVvTt6ODVBCAv6DTn8BgwAN2Rqd9t+ZYvQDrdtGJ1kzjam1kxc6R8kBUC ElfJjXo55tDaUDx1bGG9WYZJtQ3+JXKSR9RybUaQKaDhwEudFngsc7HiLPm+jmT9bkQF+IA66 iNY6RhaEC7z6h1BzdK01hl21Y1veYX3U4JDwsJQI3M2BOPknLzu/mT4uw== Subject: Re: [musl] Should fdopen() check the passed file descriptor? On Thu, Aug 04, 2022 at 02:42:49PM +0200, Sascha Brawer wrote: > Dear list > > Should musl=E2=80=99s fdopen() verify whether the passed file descriptor= refers to > an open file? > It should not. Normal musl policy for "may fail" is to just not check that. musl only implements "shall fail". In this case, using numbers that are not FDs as such is really really bad. It means the control flow is utterly br0ken. How did the program even get into a state in which a variable is supposed to be holding an FD but doesn't? It betrays a really big problem with the program if this can happen. If the program is multi-threaded (or opens files from a signal handler, which can happen since open(2) is async-signal-safe), the program might suddenly start using a file descriptor wrong. That would be an interesting problem to debug. In short, any program calling fdopen() with a number that is not guaranteed to be an open file has a logic error that needs to be fixed post-haste. Returning EBADF is really only plastering over the problem. It would be like dereferencing a pointer fresh out of malloc() and catching the SIGSEGV instead of just testing whether the pointer is 0. Ciao, Markus From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1261 invoked from network); 4 Aug 2022 16:10:01 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2022 16:10:01 -0000 Received: (qmail 20159 invoked by uid 550); 4 Aug 2022 16:09:58 -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 20124 invoked from network); 4 Aug 2022 16:09:57 -0000 Date: Thu, 4 Aug 2022 12:09:43 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com, Sascha Brawer Message-ID: <20220804160943.GV7074@brightrain.aerifal.cx> References: <20220804142322.GC3042@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220804142322.GC3042@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Should fdopen() check the passed file descriptor? On Thu, Aug 04, 2022 at 04:23:22PM +0200, Markus Wichmann wrote: > On Thu, Aug 04, 2022 at 02:42:49PM +0200, Sascha Brawer wrote: > > Dear list > > > > Should musl’s fdopen() verify whether the passed file descriptor refers to > > an open file? > > > > It should not. Normal musl policy for "may fail" is to just not check > that. musl only implements "shall fail". > > In this case, using numbers that are not FDs as such is really really > bad. It means the control flow is utterly br0ken. How did the program > even get into a state in which a variable is supposed to be holding an > FD but doesn't? > > It betrays a really big problem with the program if this can happen. If > the program is multi-threaded (or opens files from a signal handler, > which can happen since open(2) is async-signal-safe), the program might > suddenly start using a file descriptor wrong. That would be an > interesting problem to debug. > > In short, any program calling fdopen() with a number that is not > guaranteed to be an open file has a logic error that needs to be fixed > post-haste. Returning EBADF is really only plastering over the problem. > It would be like dereferencing a pointer fresh out of malloc() and > catching the SIGSEGV instead of just testing whether the pointer is 0. Yes, this is a really good explanation of the reasoning here. Moreover, in this case checking it would incur high extra cost for correct programs for the sake of producing a useless (because "may fail") error that incorrect programs can't even rely on getting. The high cost is because we'd have to do an extra probing syscall *before* doing anything with side effects. We can't even move the existing syscalls that would probe (only present in some code paths) before the malloc, because then they would have their side effects even if the malloc failed, and if we moved them afterwards, we'd have to have a failure exit path after malloc already succeeded, thus forcing free to be linked in a program that otherwise might not want it. Rich