From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Subject: Re: [d_path 0/7] Fixes to d_path: Respin Date: Sat, 21 Apr 2007 21:04:06 +0200 Message-ID: <200704212104.06349.agruen@suse.de> References: <20070412090809.917795000@suse.de> <200704201840.07247.agruen@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Alan Cox" , jjohansen@suse.de, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, chrisw@sous-sol.org, "Andrew Morton" To: "Ulrich Drepper" Return-path: In-Reply-To: Content-Disposition: inline Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Friday 20 April 2007 21:17, Ulrich Drepper wrote: > On 4/20/07, Andreas Gruenbacher 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