public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Michael Morrell <mmorrell@tachyum.com>
To: "Arsen Arsenović" <arsen@aarsen.me>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: RE: [PATCH v2] Ensure standard file descriptors are open on start
Date: Wed, 19 Aug 2020 21:04:04 +0000	[thread overview]
Message-ID: <da6549519b5440fe92a96c1acdfce4d1@tachyum.com> (raw)
In-Reply-To: <20200819194025.5sgyd5avhduime4q@bstg>

The ISO C quote says they don't need to be opened (an application can just start using them), but it doesn't say they have to be open.  It is perfectly OK for them to be closed at startup.  Also, it talks about the FILE streams stdin, stdout, and stderr, not file descriptors 0, 1, and 2.

-----Original Message-----
From: Libc-alpha <libc-alpha-bounces@sourceware.org> On Behalf Of Arsen Arsenovic via Libc-alpha
Sent: Wednesday, August 19, 2020 12:40 PM
To: Joseph Myers <joseph@codesourcery.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v2] Ensure standard file descriptors are open on start

> Please give specific references, not just "as required by POSIX and C".  
> What exactly do you think requires these descriptors to be open?
The sections that lead me to believe this were:
http://www.iso-9899.info/n1570.html#7.21.3p7
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
What would be the best way to reference these in source code? I can wait for some more potential feedback to aggregate, and for a consensus to be reached, before updating the patch with that, to reduce patch spam.

POSIX also, in other pages, occasionally mentions the danger of a file being unexpectedly open as one of three special file descriptors, which I presume is the reason for the hardening glibc was already doing for SUID binaries.

> "If a standard utility or a conforming application is executed with 
> file descriptor 0 not open for reading or with file descriptor 1 or 2 
> not open for writing, the environment in which the utility or 
> application is executed shall be deemed non-conforming, and 
> consequently the utility or application might not behave as described in this standard."
This specific part of the quote would seem to imply that standard input, output and error must be opened for reading and writing respectively?
Or do you think this only applies if the implementation decides to handle opening the file descriptors?

--
Arsen Arsenović

  reply	other threads:[~2020-08-19 21:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19 12:41 Arsen Arsenović
2020-08-19 16:28 ` Joseph Myers
2020-08-19 17:46   ` Zack Weinberg
2020-08-19 17:50     ` Joseph Myers
2020-08-19 18:20     ` Adhemerval Zanella
2020-08-19 19:13       ` Florian Weimer
2020-08-19 19:25         ` Adhemerval Zanella
2020-08-19 19:27           ` Florian Weimer
2020-08-19 19:35             ` Adhemerval Zanella
2020-08-19 19:40   ` Arsen Arsenović
2020-08-19 21:04     ` Michael Morrell [this message]
2020-08-19 22:32     ` Joseph Myers
2020-08-19 23:45       ` Arsen Arsenović
2020-08-20 22:00         ` Paul Eggert
2020-08-20 23:25           ` Arsen Arsenović
2020-08-27 15:56           ` Zack Weinberg
2020-08-27 18:21             ` Paul Eggert
2020-08-28  0:12               ` Arsen Arsenović
2020-09-04 17:49                 ` Arsen Arsenović
2020-09-11  7:47                 ` ping^2 " Arsen Arsenović
2020-08-19 23:16     ` 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=da6549519b5440fe92a96c1acdfce4d1@tachyum.com \
    --to=mmorrell@tachyum.com \
    --cc=arsen@aarsen.me \
    --cc=libc-alpha@sourceware.org \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).