Nicolas Williams writes: > On Fri, Oct 05, 2007 at 03:37:01PM -0400, James Carlson wrote: > > Don Cragun writes: > > > I'm still strongly opposed. If the path presented to the first > > > *stat*() function is a symlink pointing to an autofs/nfs directory, the > > > symlink can be changed between the *stat*() call and the opendir() call > > > and this spoofing action cannot be reliably detected by the > > > application. With AT_TRIGGER, this spoofing action can be caught every > > > time it happens. > > > > Yes. However, that's actually the same state we are in right now > > (with no fix at all), and the state we've been in since February 2005 > > when CR 6198351 integrated and added the autofs-testing logic. It's a > > hole that ought to be fixed, but it's a little less clear to me that > > it's this project team's responsibility to do so. > > This hole is not much of a hole for the autofs case because users don't > normally get to make symlinks in autofs directories. That consideration > does not apply here, so technically the change made for autofs did not > introduce a security bug, but this change would.
How's that? The proposed change looks equivalent to me in terms of security. Have you looked at the webrev? Previously, we compared st_fstype from the first stat() against "autofs" to check for trigger points, and now (with the proposed change, and in exactly the same code) we look at st_mode from the first stat() and check for the S_TRIGGER flag. The two versions do exactly the same thing functionally, so I don't see how this change introduces any flaw that isn't there today and hasn't been there for more than 2.5 years. I also agree that users can't normally write to those directories, so it's likely moot -- both before and after this project. -- 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
