mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] fdopen() doesn't check for valid fd
@ 2021-02-26 17:36 Dominic Chen
  2021-02-26 18:00 ` Rich Felker
  0 siblings, 1 reply; 5+ messages in thread
From: Dominic Chen @ 2021-02-26 17:36 UTC (permalink / raw)
  To: musl

I've been verifying the behavior of an application between glibc and 
musl, and have noticed that the musl implementation of fdopen() assumes 
that the input fd is valid, whereas glibc does not. Per 
https://pubs.opengroup.org/onlinepubs/9699919799/, it seems that 
fdopen() is allowed to fail with EBADF, so inside __fdopen(), the 
syscalls to SYS_fcntl and SYS_ioctl should probably check for an error, 
deallocate the FILE *, and return nullptr.

Thanks,

Dominic




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] fdopen() doesn't check for valid fd
  2021-02-26 17:36 [musl] fdopen() doesn't check for valid fd Dominic Chen
@ 2021-02-26 18:00 ` Rich Felker
  2021-02-27 17:13   ` Khem Raj
  0 siblings, 1 reply; 5+ messages in thread
From: Rich Felker @ 2021-02-26 18:00 UTC (permalink / raw)
  To: Dominic Chen; +Cc: musl

On Fri, Feb 26, 2021 at 12:36:19PM -0500, Dominic Chen wrote:
> I've been verifying the behavior of an application between glibc and
> musl, and have noticed that the musl implementation of fdopen()
> assumes that the input fd is valid, whereas glibc does not. Per
> https://pubs.opengroup.org/onlinepubs/9699919799/, it seems that
> fdopen() is allowed to fail with EBADF, so inside __fdopen(), the
> syscalls to SYS_fcntl and SYS_ioctl should probably check for an
> error, deallocate the FILE *, and return nullptr.

This is specified as a "may fail" error not a "shall fail". It was
discussed before (I can look up the old thread if you're interested)
and there are some paths in which checking for it would be free, but
others where it would not, and it would require reorganizing the
function's flow in a way that's less desirable in one way or another,
so it doesn't seem like a good idea for the sake of something a caller
can't actually use.

Rich

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] fdopen() doesn't check for valid fd
  2021-02-26 18:00 ` Rich Felker
@ 2021-02-27 17:13   ` Khem Raj
  2021-02-27 17:35     ` Rich Felker
  0 siblings, 1 reply; 5+ messages in thread
From: Khem Raj @ 2021-02-27 17:13 UTC (permalink / raw)
  To: musl; +Cc: Dominic Chen

On Fri, Feb 26, 2021 at 10:01 AM Rich Felker <dalias@libc.org> wrote:
>
> On Fri, Feb 26, 2021 at 12:36:19PM -0500, Dominic Chen wrote:
> > I've been verifying the behavior of an application between glibc and
> > musl, and have noticed that the musl implementation of fdopen()
> > assumes that the input fd is valid, whereas glibc does not. Per
> > https://pubs.opengroup.org/onlinepubs/9699919799/, it seems that
> > fdopen() is allowed to fail with EBADF, so inside __fdopen(), the
> > syscalls to SYS_fcntl and SYS_ioctl should probably check for an
> > error, deallocate the FILE *, and return nullptr.
>
> This is specified as a "may fail" error not a "shall fail". It was
> discussed before (I can look up the old thread if you're interested)
> and there are some paths in which checking for it would be free, but
> others where it would not, and it would require reorganizing the
> function's flow in a way that's less desirable in one way or another,
> so it doesn't seem like a good idea for the sake of something a caller
> can't actually use.
>

perhaps we should add it to differences with glibc document [1]

> Rich

[1] https://wiki.musl-libc.org/functional-differences-from-glibc.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] fdopen() doesn't check for valid fd
  2021-02-27 17:13   ` Khem Raj
@ 2021-02-27 17:35     ` Rich Felker
  2021-02-27 17:42       ` Khem Raj
  0 siblings, 1 reply; 5+ messages in thread
From: Rich Felker @ 2021-02-27 17:35 UTC (permalink / raw)
  To: Khem Raj; +Cc: musl, Dominic Chen

On Sat, Feb 27, 2021 at 09:13:17AM -0800, Khem Raj wrote:
> On Fri, Feb 26, 2021 at 10:01 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Fri, Feb 26, 2021 at 12:36:19PM -0500, Dominic Chen wrote:
> > > I've been verifying the behavior of an application between glibc and
> > > musl, and have noticed that the musl implementation of fdopen()
> > > assumes that the input fd is valid, whereas glibc does not. Per
> > > https://pubs.opengroup.org/onlinepubs/9699919799/, it seems that
> > > fdopen() is allowed to fail with EBADF, so inside __fdopen(), the
> > > syscalls to SYS_fcntl and SYS_ioctl should probably check for an
> > > error, deallocate the FILE *, and return nullptr.
> >
> > This is specified as a "may fail" error not a "shall fail". It was
> > discussed before (I can look up the old thread if you're interested)
> > and there are some paths in which checking for it would be free, but
> > others where it would not, and it would require reorganizing the
> > function's flow in a way that's less desirable in one way or another,
> > so it doesn't seem like a good idea for the sake of something a caller
> > can't actually use.
> >
> 
> perhaps we should add it to differences with glibc document [1]
> 
> > Rich
> 
> [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html

I'm not fundmanetally opposed to that, but it should probably be a
more general statement about "may fail" and UB; otherwise we'd end up
documenting a very large number of little details like this one.

Rich

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] fdopen() doesn't check for valid fd
  2021-02-27 17:35     ` Rich Felker
@ 2021-02-27 17:42       ` Khem Raj
  0 siblings, 0 replies; 5+ messages in thread
From: Khem Raj @ 2021-02-27 17:42 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl, Dominic Chen

On Sat, Feb 27, 2021 at 9:35 AM Rich Felker <dalias@libc.org> wrote:
>
> On Sat, Feb 27, 2021 at 09:13:17AM -0800, Khem Raj wrote:
> > On Fri, Feb 26, 2021 at 10:01 AM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Fri, Feb 26, 2021 at 12:36:19PM -0500, Dominic Chen wrote:
> > > > I've been verifying the behavior of an application between glibc and
> > > > musl, and have noticed that the musl implementation of fdopen()
> > > > assumes that the input fd is valid, whereas glibc does not. Per
> > > > https://pubs.opengroup.org/onlinepubs/9699919799/, it seems that
> > > > fdopen() is allowed to fail with EBADF, so inside __fdopen(), the
> > > > syscalls to SYS_fcntl and SYS_ioctl should probably check for an
> > > > error, deallocate the FILE *, and return nullptr.
> > >
> > > This is specified as a "may fail" error not a "shall fail". It was
> > > discussed before (I can look up the old thread if you're interested)
> > > and there are some paths in which checking for it would be free, but
> > > others where it would not, and it would require reorganizing the
> > > function's flow in a way that's less desirable in one way or another,
> > > so it doesn't seem like a good idea for the sake of something a caller
> > > can't actually use.
> > >
> >
> > perhaps we should add it to differences with glibc document [1]
> >
> > > Rich
> >
> > [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html
>
> I'm not fundmanetally opposed to that, but it should probably be a
> more general statement about "may fail" and UB; otherwise we'd end up
> documenting a very large number of little details like this one.
>

Perhaps that better since it will cover a broad range of issue. We
might sight this as an example there perhaps and suggest to watch for
such usecases.

> Rich

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-02-27 17:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-26 17:36 [musl] fdopen() doesn't check for valid fd Dominic Chen
2021-02-26 18:00 ` Rich Felker
2021-02-27 17:13   ` Khem Raj
2021-02-27 17:35     ` Rich Felker
2021-02-27 17:42       ` Khem Raj

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).