linux-kernel - RE: [Nfs-ganesha-devel] name_to_handle

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] [day] [month] [year] [list]

Message-ID: <009901cf4202$7c310970$74931c50$@mindspring.com>
Date:	Mon, 17 Mar 2014 10:01:03 -0700
From:	"Frank Filz" <ffilzlnx@...dspring.com>
To:	"'Aneesh Kumar K.V'" <aneesh.kumar@...ux.vnet.ibm.com>,
	"'Michael Kerrisk'" <mtk.manpages@...il.com>
Cc:	"'Andreas Dilger'" <adilger@...ger.ca>,
	<linux-man@...r.kernel.org>,
	"'Miklos Szeredi'" <miklos@...redi.hu>,
	"'NeilBrown'" <neilb@...e.de>,
	"'Linux Kernel'" <linux-kernel@...r.kernel.org>,
	"'Christoph Hellwig'" <hch@...radead.org>,
	"'Linux-Fsdevel'" <linux-fsdevel@...r.kernel.org>,
	"'Ganesha NFS List'" <nfs-ganesha-devel@...ts.sourceforge.net>
Subject: RE: [Nfs-ganesha-devel] name_to_handle_at() and persistent	filesystem IDs

> Michael Kerrisk <mtk.manpages@...il.com> writes:
> 
> > Hello Aneesh,
> >
> > I'm currently working on a man page for name_to_handle_at() and
> > open_by_handle_at(), and I have a question relating to a point that
> > probably needs to be covered in the man page.
> >
> > Back in July 2010, in this thread:
> > http://thread.gmane.org/gmane.linux.file-systems/41782/focus=43131
> > you said:
> >
> > [[
> > mount id should not be looked at as a persistent identifier. It should
> > be used to derive a persistent identifier from /proc/self/mountinfo.
> > The persistent identifier could be the combination of device
> > properties, file system properties or the uuid which is going to be an
> > optional tag in /proc/self/mountinfo.
> > ]]
> >
> > In the man page, I'd like to briefly describe how one derives such a
> > persistent ID from mountinfo. AFAICS, the optional UUID tag in
> > /proc/self/mountinfo has not come to pass. So, what then is the
> > recommended practice for deriving the persistent ID?
> >
> 
> Anything that work for the application. mount_id will indicate which mount
it
> is ie. from /proc/self/mountinfo
> 
> 30 20 8:1 / /boot rw,relatime - ext4 /dev/sda1 rw,data=ordered
> 
> The value 30 helps us to figure out that we are looking at device
/dev/sda1.
> With that we can derive the uuid using libblkid.  I am not sure we
concluded
> anything really about how to identify an nfs mount. May be we can do that
> based on server and mount point details ?.But from the syscall point, what
> we return is mount_id, which gives a hint regarding which mount point we
> are talking about in /proc/self/mountinfo. From that information
applications
> can use any method that work for them to derivce an unique identifier.
> 
> I know that NFS ganesha use these syscall. May we can check with them
> what worked for them ? (Added to CC:)

Ganesha ignores the mount id. It's not really clear how it would be used
(would it help detect file system junctions?) since it isn't required on
open_by_handle_at, it's just a return param from name_to_handle_at.

Frank

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