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

[Aneesh Kumar K. V]

On Thu, 13 May 2010 02:30:46 -0600, Andreas Dilger <andreas.dilger@xxxxxxxxxx> wrote:
> 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.


I guess we also have the problem with readonly bind mounts.  May be we
should use the mountdir fd and leave the fsid to mountdir fd mapping to
userspace. 

NOTE: With the current patchset a name_to_handle on the readonly mount
point will fail because of the new checks i added in the syscall. But in
general i guess we need to make sure that an open_by_handle should
follow these vfsmount flags also. 

Christoph, Andreas,

Can we agree on the use of mountdir fd ? If so i can redo the patch
using mountdirfd.

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/