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