Don Cragun writes:
>       This case tries to allow applications to determine that they
> have just stat()ed a file that may generate a false positive.  It does
> do that.  But there is still no way to determine whether the directory
> opened by the opendir() was the requested directory or a spoofed
> directory planted into the file hierarchy between the original *stat*()
> call and the opendir() call.

Yes, that's exactly the point I was raising.

The problem is that doing two stats after opendir() doesn't really add
any security, as it doesn't cover for a race condition that anyone has
been able to describe, so I think we ought to be direct and say that
we are deliberately disabling this security check in this one case.

The code presented showed two fstat() calls on the same file
descriptor, and a compare of the results.  If those don't show the
same node, then I think the machine should be panicked.  ;-}

Even if the code were changed to do stat() first (after the opendir()
that causes the trigger) and then an fstat(), it's not clear what
we're protecting against.  I don't see the threat model.  We're going
to do an fchdir() to the file descriptor returned by opendir(), so who
cares whether the identity of the object named by the original path
has been changed in the meantime?  Couldn't it change at _any_ point
between the new stat() call and the fchdir()?  If so, such a change
would be undetected, and thus we're not gaining any security.

>  Since it leaves the security hole
> unplugged, I don't see that it buys us anything while it any
> application trying to use this feature unportable.

Assuming that other OSes present the same problem -- mere stat()
doesn't trigger a fetch of the correct information, but opendir() does
-- it'd be nice to see a standards-based solution for this.  I'm not
sure that's a requirement here, though.

I think the alternative (one that preserves the existing security
checks) would be to add a new flag to fstatat(2).  Create a new flag
called (say) AT_TRIGGER, and have it invoke the same autofs triggering
that opendir() does, so that the node information returned is
correct.  That way, you wouldn't have to do the double stat after
opendir return, or disable the test.

I have no idea how hard that might be, though.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to