>Date: Thu, 04 Oct 2007 23:15:55 -0500 >From: Tom Haynes <Thomas.Haynes at sun.com> >James Carlson wrote: >> 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. >> > >Agreed, I can't express the race condition that I believed was still there. > >I also agree with the statement that we need to be direct here. > > >> I think the alternative (one that preserves the existing security >> checks) would be to add a new flag to fstatat(2). >> > >That approach would trigger a mount before the call to fstatat(2). The >key design >point in my proposal is that we want to be able to detect that a >directory is a >trigger mount without actually triggering the mount.
Any approach that doesn't force the mount is going to leave a security hole. The security hole while doing an ls -l probably isn't important. I understand that there is a significant performance penalty forcing mounts on all *stat*() calls. But surely we can force the mounts if an application explicitly asks for it in an fstatat() call when it knows that skipping the mount may lead to an otherwise undetectable security hole. Both ftw() and nftw() should ask for it. (Forcing the mount on the fstatat() in ftw() and nftw() will make them run faster; not slower. They will be forcing the mounts anyway and this avoids additional checks that have been added trying to plug the security hole that was created by cases approved earlier.) I strongly suggest that you reconsider Jim's suggestion. I also strongly suggest again, that you run this by IBM, HP, and RedHat to try to get buy-in for us all doing this the same way. If you need contacts, I can supply them. (With current timing constraints, I don't see any way to get a new fstatat() flag into the upcoming revision of POSIX.1-2001 and SUSv3; but if we get buy in from the other OS vendors participating in The Austin Group, we should be able to add it into the next revision.) - Don
