From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) by sourceware.org (Postfix) with ESMTPS id 6567E3857C4D for ; Thu, 20 Aug 2020 23:25:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6567E3857C4D Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4BXgkL0rJLzQlFd; Fri, 21 Aug 2020 01:25:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id snGCw054hVPc; Fri, 21 Aug 2020 01:25:42 +0200 (CEST) Date: Fri, 21 Aug 2020 01:25:41 +0200 From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Paul Eggert Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v2] Ensure standard file descriptors are open on start Message-ID: <20200820232541.ccwg56iygdilkeuv@bstg> References: <20200819124124.17481-1-arsen@aarsen.me> <20200819194025.5sgyd5avhduime4q@bstg> <20200819234519.l4enjvx4fsw42ltl@bstg> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="syp4auvvsgoraebq" Content-Disposition: inline In-Reply-To: X-MBO-SPAM-Probability: X-Rspamd-Score: -5.33 / 15.00 / 15.00 X-Rspamd-Queue-Id: 1420B679 X-Rspamd-UID: b52808 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 23:25:48 -0000 --syp4auvvsgoraebq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >>> This specific part of the quote would seem to imply that standard > >>> input, output and error must be opened for reading and writing > >>> respectively? > >> > >> Yes - that is, what the implementation does if standard input is not > >> open for reading, or standard output and error are not open for writin= g, > >> is not specified. > > The "may" in the sentence indeed does leave it unspecified, but it seems > > hinted that these file descriptors should be open for startup. >=20 > I'm not following this; what "may" is being referred to here? In this sentence: "If file descriptor 0, 1, or 2 would otherwise be closed = after a successful call to one of the exec family of functions, implementations *= MAY* open an unspecified file for the file descriptor in the new process image." > "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 mig= ht > not behave as described in this standard." >=20 > What this is saying, is that if program A executes program B with messed-= up > file descriptors 0, 1, or 2, then B's behavior is not specified. That is, > POSIX does not place any requirement on the Glibc startup in B, and Glibc= can > do whatever it wants in this situation. I see. So the question becomes is it desirable for glibc to do anything, not whether POSIX requires it to be so. > > It also says that this should only happen if a special file descriptors > > stays closed after exec, so there is no need to worry about the case wh= ere > > the parent makes fd 0 write only. > > I don't understand this remark. This is referring to the quote above, the implementation may decide to open= a file in their place, if it would be otherwise closed in the new process ima= ge, which would mean in the case that the file was open but in the wrong mode (= e.g. stdin as write only) glibc should do nothing, eliminating that case, and the analog cases for stdout/err. > > And considering the hint, and that the edge case of stdin being closed > > seems to have been missed even by the autotools developers (I noticed t= his > > when running autoconf-1.64s ./configure from an automation tool that cl= osed > > fd 0) >=20 > If Autoconf doesn't operate well when file descriptor 0 is closed then it > might be worth changing Autoconf, if it's not too much trouble. But becau= se of > the above quotation from POSIX, no change to Autoconf can be solve this > problem on all possible POSIX platforms, because POSIX does not specify h= ow > the 'autoconf' command (which is a shell script) will work if you invoke = it > with file descriptor 0 closed. >=20 > If you want a portable fix to this problem, you can fix the build procedu= re > that calls Autoconf so that it does not close file descriptor 0. This is a > good idea anyway, as closing fd 0 can break any program on a POSIX platfo= rm. I've already implemented a fix in the build procedure, but as I understood = it at the time, the problem was external at it's root. > > Also, the sentence talked about here seems to be pretty explicit: either > > the implementation opens fd 0 for reading and fds 1 and 2 for writing, = or > > it is non-conforming. >=20 > No, the quotation doesn't say that. It says that if program A invokes pro= gram > B with fd 0 closed, then B's behavior is not specified. This is a constra= int > on program A, not on the libc implementation. >=20 > There's a good reason glibc, if it's to do anything, should open fd 0 with > (say) O_PATH instead of O_RDONLY when fd 0 is closed: this would help cat= ch > bugs in programs. Programs should not rely on a closed fd 0 behaving as i= f it > were reading from /dev/null. I agree, that makes most sense if the constraint I was talking about is not= on glibc, which it appears to be the case. It would also explain why this was previously done for SUID binaries, bugs in those can be very dangerous, but= bugs outside of those can be very dangerous, too, for the same reasons (say, an application writing a log message to fd 3 directly, which, due to the caller closing fd 3 actually turned out to be a database connection, it is better = to fail than to send possibly dangerous content to an undefined place). --=20 Arsen Arsenovi=C4=87 --syp4auvvsgoraebq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEN603JsCUe+6MiEcuSj/KZcFT9D4FAl8/BnUACgkQSj/KZcFT 9D4Obgf/YIAbSZbMXbzeEDNDAc5bSntjGhoON1g0Gl6S+XTua23LPqE76chUqcEn Bqs2cjfrO1+WxuWLkR6oQrt1v7avO+67z/8Kd4o9UXyxrY4sjvrWI856TAAS+qrn 7a4e5iJa7Fo6SmufhUaLjHQ1QZTwbRrmtk5yMHZ4mAQebiWdEX5hO9N1Lri+CLE8 w7nK9Lb1wYV1FPvFsWWv0kjPbvXJ6a8q2I1a1tFK959tj5lekunkvu4ojUf+DydH YBRq7xgUE85SPQeNZnt/jT/8UrUlB5mP/6xkj4+lRQviUf6Rt02ATZ26vKSVWpRG EzAtoUNMyLYK5pXgG50Fh7aUksqUPw== =QgaO -----END PGP SIGNATURE----- --syp4auvvsgoraebq--