Re: [PATCH v2] Ensure standard file descriptors are open on start

[Paul Eggert <eggert@cs.ucla.edu>]

 >>> 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 writing,
 >> 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.

I'm not following this; what "may" is being referred to here?

Here's the quote again, from
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/execve.html>:

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

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.

 > 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 where
 > the parent makes fd 0 write only.

I don't understand this remark.

 > 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 this
 > when running autoconf-1.64s ./configure from an automation tool that closed
 > fd 0)

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 because 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 how
the 'autoconf' command (which is a shell script) will work if you invoke it
with file descriptor 0 closed.

If you want a portable fix to this problem, you can fix the build procedure
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 platform.

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

No, the quotation doesn't say that. It says that if program A invokes program
B with fd 0 closed, then B's behavior is not specified. This is a constraint
on program A, not on the libc implementation.

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 catch
bugs in programs. Programs should not rely on a closed fd 0 behaving as if it
were reading from /dev/null.