linux-kernel - Re: Adding subroot information to /proc/mounts, or obtaining that through other means

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: <467B7509.8010106@zytor.com>
Date:	Fri, 22 Jun 2007 00:06:49 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ram Pai <linuxram@...ibm.com>
CC:	Al Viro <viro@....linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, util-linux-ng@...r.kernel.org
Subject: Re: Adding subroot information to /proc/mounts, or obtaining that
 through other means

Ram Pai wrote:
> 
> the second patch made a /proc/propagation interface which had almost the
> same fields, but also added fields to show the propagation type of the
> mount as well as pointers to its peers and master depending on the type
> of the mount. 
> 
> I think the consensus seems to have a new interface /proc/make-a-name
> which extends the interface provided by /proc/mounts but provides the
> propagation state of the mounts too as well as disambiguate bind mounts.
> Which makes sense.
> 

Why?  It seems a lot cleaner to have all the information in the same
place.  It is highly unfriendly to userspace to have to gather
information in a lot of places, plus it adds race conditions.

It would be another matter if the format that we have now couldn't be
extended, but we need those fields (well, except the two zeros, but who
cares) *anyway*, so we might as well stick to the existing file, and
reduce the total amount of code and clutter.

> 
> BTW: what is the need for overmounted flag?  Do you mean two vfsmounts
> mounted on the same dentry on the ***same vfsmount*** ?
> 

Maybe I'm not following the uses of your flags well enough to figure out
 if that information can already been deduced.

	-hpa
-
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/