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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704201840.07247.agruen@suse.de>
Date:	Fri, 20 Apr 2007 18:40:07 +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 17:24, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <agruen@...e.de> wrote:
> > Yes, that one, sorry. The values it obtains that way are not reliable.
>
> Why should the mount point info together with the filesystem type not
> be reliable?

Ah ... I overlooked that fstatvfs() also checks the device number, not only 
the name, and so then it can find the right device from that.

So for how glibc uses /proc/mounts in fstatvfs(), hiding unreachable mount 
points from /proc/mounts wouldn't improve things. The heuristic already 
doesn't work for file descriptors from other namespaces, so it's already 
broken unfortunately. A more robust mechanism for glibc to use would be nice; 
not sure it would be worth it only for fstatvfs though.

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.,

	$ dd if=/dev/zero of=/var/tmp/ext2 bs=4096 count=16384
	$ mkfs.ext2 -F /var/tmp/ext2
	$ mount -o loop /var/tmp/ext2 /mnt
	$ mount -o loop,ro /var/tmp/ext2 /mnt
	$ tail -n 2 /proc/mounts
	/dev/loop0 /mnt ext2 rw 0 0
	/dev/loop1 /mnt ext2 ro 0 0

The topmost mount point appears last in /proc/mounts, and so unless I am 
overlooking something else, that's another minor problem.

The third problem, as I already tried to argue several times now, is that the 
mount points path that /proc/mounts reports may or may not actually exist. 
That's a problem for glibc, and you should be one of the first to notice and 
acknowledge that. 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.

> You're trying to find an excuse to break tings, that seems all there is.

Now what makes you think that??

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ