> >>> 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?
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 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.
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 where
> > 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 image,
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 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.
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.
> 
> 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.
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).

-- 
Arsen Arsenović