On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > The code also seems to stop at the first matching mount point. You can
> > have the same device mounted on the same mount point multiple times but
> > with different mount options, e.g., [...]
>
> You can unfortunately do many stupid things. That's the user's
> problem. The point is that everything works fine in an environment
> which does not have such bogus mounts.
What I described is a supported feature, nothing more and nothing less. It's
also relatively easy to handle this case correctly in glibc, e.g.,
--- a/sysdeps/unix/sysv/linux/internal_statvfs.c
+++ b/sysdeps/unix/sysv/linux/internal_statvfs.c
@@ -139,6 +139,7 @@ __statvfs_getflags (const char *name, in
char *cp = mntbuf.mnt_opts;
char *opt;
+ result = 0;
while ((opt = strsep (&cp, ",")) != NULL)
if (strcmp (opt, "ro") == 0)
result |= ST_RDONLY;
@@ -157,9 +158,10 @@ __statvfs_getflags (const char *name, in
else if (strcmp (opt, "nodiratime") == 0)
result |= ST_NODIRATIME;
- /* We can stop looking for more entries. */
success = true;
- break;
+ /* Don't stop looking: the same device may be mounted several
+ times with different options; in that case, the last entry
+ is the topmost mount. */
}
}
/* Maybe the kernel names for the filesystems changed or the
> > I gave a chroot example that showed that in the current implementation,
> > you can get pretty random clashes between mounts; there are other cases
> > with lazy unmounts as well.
>
> Irrelevant as well. If you create chroot problems it's your problem.
There is no way to avoid these problems with chroots; it's not that anybody
creates stupid problems on purpose.
The approach I'm proposing fixes these problems. It has a small disadvantage
for statvfs / fstatvfs in some situations, which is due to the fact that the
kernel doesn't offer a direct interface for querying the mount options of a
file descriptor or path, and so glibc has to resort to messing
with /proc/mounts. I don't see a nice way of fixing this without introducing
[f]statvfs syscalls right now.
This is what POSIX says about statvfs / fstatvfs:
> It is unspecified whether all members of the statvfs structure have
> meaningful values on all file systems.
In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts
by far outweighs the problems is sometimes causes for fstatvfs(). Anyone
relying on the information obtained from statvfs / fstatvfs is making false
assumptions anyway, and in "normal setups" as you called them, nothing
changes for fstatvfs and statvfs.
Andreas
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
