linux-kernel - Re: [PATCH -V7 3/9] vfs: Add name to file handle conversion support

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: <51B2B398-99A7-43BF-A074-ACFBBA318DF7@oracle.com>
Date:	Thu, 13 May 2010 02:30:46 -0600
From:	Andreas Dilger <andreas.dilger@...cle.com>
To:	Neil Brown <neilb@...e.de>
Cc:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Jonathan Corbet <corbet@....net>,
	Serge Hallyn <serue@...ibm.com>, linux-fsdevel@...r.kernel.org,
	Steven French <sfrench@...ibm.com>,
	Philippe Deniel <philippe.deniel@....FR>,
	"linux-kernel@...r.kernel.org Mailinglist" 
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -V7 3/9] vfs: Add name to file handle conversion support

On 2010-05-13, at 01:11, Neil Brown wrote:
> Here is my reason (well, one of my reasons) why UUID is clearly not an
> acceptable handle to use - you *must* use an fd or are worst a path name.
> 
> A filesystem can be mounted at multiple places in the namespace and each
> instance can have other filesystems mounted on different directories.
> Each of these is a 'vfsmnt'.
> You need a vfsmnt for most (all?) filesystem operations.
> A UUID does not uniquely identify a vfsmnt.  It might uniquely identify a
> filesystem, though that is debatable.  It definitely does not uniquely
> identify a vfsmnt.
> Therefore, given only a UUID the kernel would have to arbitrarily choose a
> vfsmnt that references to the right filesystem.  If a particular directory in
> the filesystem that you want to access was mounted-on in that vfsmnt, that
> directory would be completely inaccessible to you, even though it might be
> completely accessible in some other vfsmnt.
> So it is quite possible for a scheme based on kernel interpretation of uuids
> to fail.

I think this is exactly the wrong solution for this case.  The lookup from pathname to handle happened ALREADY (in the presence of the right namespace and vfsmnt information) and all that should be required for the handle lookup is to get the exact same inode back from disk.  It is irrelevant what vfsmnt is used to do this lookup, so long as it is in the same filesystem as before.

> This may be a corner case, but I think people are slowly getting more
> adventurous in terms of using the mount table to do interesting things.  It
> may be less of a corner case in 5 years.

I think the important feature for the handle is that _regardless_ of what shenanigans are done with the path, over-mounting of directories, etc, that the same inode is returned.  One would expect that if a real fd was opened by a process, that any later changes to the namespace would not suddenly result in another file with the same pathname to be accessible by that fd.
 
> So to tell the kernel which filesystem is of interest for filehandle
> lookup, you *must* give it a name, whether a textual path, or a filehandle
> obtained by opening a textual path.

No, that is done at the time of open() (or in this case name_to_handle()) and afterward the name/path/vfsmnt is completely irrelevant to the fd/handle.

Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.

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