Re: [PATCH -V3] Generic name to handle and open by handle syscalls

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Aneesh Kumar K.V (aneesh.kumar@linux.vnet.ibm.com):
> Hi,
> 
> The below set of patches implement open by handle support using exportfs
> operations. This allows user space application to map a file name to file 
> handle and later open the file using handle. This should be usable
> for userspace NFS [1] and 9P server [2]. XFS already support this with the ioctls
> XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE.
> 
> [1] http://nfs-ganesha.sourceforge.net/
> [2] http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01087.html
> 
> TODO:
> I guess we would need to optimize how we get the vfsmount for the filesystem
> uuid specified. Searching the file system list and task name space may be a big
> overhead for each open by handle call.
> 
> Chages from V2:
> a) Support system wide unique handle.
> 
> Changes from v1:
> a) handle size is now specified in bytes
> b) returns -EOVERFLOW if the handle size is small
> c) dropped open_handle syscall and added open_by_handle_at syscall
>    open_by_handle_at takes mount_fd as the directory fd of the mount point
>    containing the file
> e) handle will only be unique in a given file system. So for an NFS server
>    exporting multiple file system, NFS server will have to internally track the
>    mount point to which a file handle belongs to. We should be able to do it much
>    easily than expecting kernel to give a system wide unique file handle. System
>    wide unique file handle would need much larger changes to the exportfs or VFS
>    interface and I was not sure whether we really need to do that in the kernel or
>    in the user space
> f) open_handle_at now only check for DAC_OVERRIDE capability

Hi Aneesh,

it still scares me a bit as I expect to see some privileged userspace
daemon accept (forged) handles from unprivileged users and pass back
open fds, but adding some random token to prevent that would require
storing it, so I think you're doing what you reasonably can by
requiring DAC_OVERRIDE.

nsproxy bit looks fine, and i saw no problems in the rest of the set.
As Andreas was saying I don't see why you're calling it _at, but
meanwhile

Acked-by: Serge Hallyn <serue@us.ibm.com>

to the set.

-serge