Tom Haynes writes:
> James Carlson wrote:
> > Rich.Brown at Sun.COM writes:
[...]
> >> stat(szPath, &statPre);
> >> pdir = opendir(szPath);
> >>
> >> if (S_ISTRIGGER(statPre.st_mode)) {
> >> stat(szPath, &statPre);
> >> }
> >>
> >> fstat(pdir->dd_fd, &statFile);
> >>
> >> if (statPre.st_ino != statFile.st_ino ||
> >> statPre.st_dev != statFile.st_dev) {
> >> return(EAGAIN);
> >> }
> >>
> >
> > If doing the stat() call after opendir() works correctly for trigger
> > points, why would it not work for all other object types?
> >
> > I don't quite see what the stat-after-opendir tells you that the
> > fstat() does not.
[...]
> The intent of the stat-after-opendir is to refresh the statPre buffer
> with the
> inode and device that were loaded as a result of the opendir() causing a
> trigger mount to fire.
Yes, I see that part.
> For all other object types, the stat-before-opendir will match the
> stat-after-opendir.
> For trigger mounts, they will not.
Yep; understood.
My question was about how this results in a "security check" and how
three calls to stat() (or, rather, one stat() call and two fstat()
calls) would achieve some sort of security.
Now that I've looked at the code, I think I understand what's really
going on, so let me try to recast it and see if this matches your
intended results:
For all entries, do the stat() first, because the stat() results are
what we normally pass along to the user. For directories, open the
node. Check, for security reasons, whether fstat() after opening the
directory matches the stat() results before opening.
However, if that first stat() call reveals that it's a trigger point,
then don't bother doing any security test at all. We know it'll
change to something new on opendir(), and that's just how it is.
The part that tripped me up here was the double stat(). The actual
code seems to use a "stat-opendir-fstat-fstat" pattern, where that
first fstat is the "new" one, and is actually there just to dummy out
the results from the second one. (As a code review comment, it looks
like this dummying-out could be done by way of a boolean_t rather than
calling fstat() an extra time merely to overwrite &statb.)
--
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
