On Thu, 22 Apr 2010 17:49:58 -0500, "Serge E. Hallyn" <serue@xxxxxxxxxx> wrote: > Quoting Aneesh Kumar K.V (aneesh.kumar@xxxxxxxxxxxxxxxxxx): > > 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. We still do access permission check using the file permission modes. What we don't do is to check the execute (x) bit on the directory. But the idea of adding DAC_OVERRIDE is to make sure that we allow only privileged user to use the open by handle interface. > > 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@xxxxxxxxxx> I missed adding Acked-by: in V4 iteration. But will add in V5 iteration. Can i add the same to all the patches ? Or do you want me to add only to the nsproxy bits. > > to the set. > > -serge -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
