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):
> On Thu, 22 Apr 2010 17:49:58 -0500, "Serge E. Hallyn" <serue@us.ibm.com> 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 <serue@us.ibm.com>
> 
> 
> 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