mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Cc: Sascha Brawer <sascha@brawer.ch>
Subject: Re: [musl] Should fdopen() check the passed file descriptor?
Date: Thu, 4 Aug 2022 16:23:22 +0200	[thread overview]
Message-ID: <20220804142322.GC3042@voyager> (raw)
In-Reply-To: <CABKQ4ESdWjkiMYGLmKan8kG5EXhXgV1kw2Da3uniGgkJ0vfeCQ@mail.gmail.com>

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.

Ciao,
Markus

  reply	other threads:[~2022-08-04 14:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 12:42 Sascha Brawer
2022-08-04 14:23 ` Markus Wichmann [this message]
2022-08-04 16:09   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220804142322.GC3042@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    --cc=sascha@brawer.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).