linux-kernel - Re: [d_path 0/7] Fixes to d

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704212104.06349.agruen@suse.de>
Date:	Sat, 21 Apr 2007 21:04:06 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	"Ulrich Drepper" <drepper@...il.com>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [d_path 0/7] Fixes to d_path: Respin

On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <agruen@...e.de> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/