From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH -V3] Generic name to handle and open by handle syscalls Date: Fri, 23 Apr 2010 08:49:50 -0500 Message-ID: <20100423134950.GB6984@us.ibm.com> References: <1271960133-16414-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <20100422224958.GA22130@us.ibm.com> <87k4ryjstz.fsf@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hch@infradead.org, viro@zeniv.linux.org.uk, adilger@sun.com, corbet@lwn.net, linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com To: "Aneesh Kumar K. V" Return-path: Received: from e36.co.us.ibm.com ([32.97.110.154]:36761 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757415Ab0DWNuI (ORCPT ); Fri, 23 Apr 2010 09:50:08 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3NDl0pj032159 for ; Fri, 23 Apr 2010 07:47:00 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3NDnr4R085198 for ; Fri, 23 Apr 2010 07:49:53 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3NDnpI6018206 for ; Fri, 23 Apr 2010 07:49:52 -0600 Content-Disposition: inline In-Reply-To: <87k4ryjstz.fsf@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com): > On Thu, 22 Apr 2010 17:49:58 -0500, "Serge E. Hallyn" wrote: > > 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. > > We still do access permission check using the file permission > modes. Hmm? Just to be clear - you do that check at name_to_handle(), though of course that doesn't help prevent forgeries. At open_by_handle you do dentry_open(), but since you require CAP_DAC_OVERRIDE anyway, we of course know that the task doing open_by_handle() will have all the perms it needs to open the file, and more :) Which, alas, is why this will be less ideal for checkpoint/restart than I had hoped. Certainly a privileged task can restart an unprivileged one, but it then has to be more careful about the authenticity of the contents of the checkpoint file. For the re-opening of checkpointed files to be re-authorized according to the permissions of the checkpointed task, the unprivileged user has to be able to do restart himself. Hmm, suppose we could add a re-authorize phase before returning to userspace where we double-check... > 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 > > > 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. All the patches. thanks, -serge