Re: several changes today

[Roland McGrath <roland@frob.com>]

> Roland, did you took a look at the code?  

I have now, and I am even more concerned about it than before.  The fact
that you would even consider putting in a stat by name before the open and
think that might be in any way appropriate or sufficient substitute is very
disturbing to me.

> There still is a stat, but it is before the open.  This stat is necessary
> since otherwise you could open, say, /dev/st0, and rewind a tape or so.

A `stat' by name before the open is insufficient for POSIX.1 requirements.
The name could be changed from a directory to a nondirectory between the
stat and the open.  One can write POSIX.1-conformant programs and use them
in a way conformant to POSIX.1 and POSIX.2 that will produce this situation
at least as a race possibility.  It is unacceptable to allow this possibility.

> What is left out in the case when O_DIRECTORY is defined is the second
> fstat call, right after the open.  Note, it is still there for systems
> which don't provide O_DIRECTORY but I've removed it otherwise since it
> is in any case no real solution.  If somebody can replace the
> directory tested with the initial stat() call with something which is
> no directory in the time between the stat and the open, s/he can as
> well replace it with a symlink to /dev/st0 or so.  

That is a potential problem in practice, but allowing that possibility does
not violate POSIX.  (Nor does it violate POSIX to check twice, just in
case.  It would be acceptable to do stat + open + fstat; the stat before
open is not required by POSIX, but addresses your concern above.)

With open + fstat, there is no possibility that opendir will open the file
and incorrectly believe it to be a directory, because the fstat tells
opendir the directoryness of the thing it did in fact open, and the name
(which might have changed) is never relevant again.  Allowing that
possibility violates POSIX.

> Therefore the only 100% solution is to not let the kernel open something
> which is no directory and then the second fstat is not necessary.

I agree that open with a kernel that supports O_DIRECTORY is a fully
sufficient solution.  You have defined for yourself what "100% solution"
means, to mean something more restrictive than what POSIX requires.  That
is a fine thing to desire, but the logic that since you've thought of this
solution, nothing else is worth doing if it allows any possibilities that
O_DIRECTORY does not, is completely faulty.  

Unless you declare that future glibc releases require linux-2.1.126 or
later (or whatever it is that has O_DIRECTORY with this functionality), 
then you have broken the POSIX.1 compliance of glibc-based systems,
and that is utterly unacceptable to many more people than just me.

I have no problem with the argument that the "highest quality of
implementation" vis a vis this issue is provided by the O_DIRECTORY
functionality.  But all that is required for POSIX.1 compliance is to check
with fstat after the open, and to fail to do either is manifestly and
importantly different and worse than "mere" POSIX.1 compliance without the
highest possible quality of implementation.