On Wed, Dec 06, 2006 at 10:20:23AM -0600, Rob Ross wrote: > Matthew Wilcox wrote: > >On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote: > >>David Chinner wrote: > >>>Does anyone here know about the XFS libhandle API? This has been > >>>around for years and it does _exactly_ what these proposed syscalls > >>>are supposed to do (and more). > >>Thanks for pointing these out Dave. These are indeed along the same > >>lines as the openg()/openfh() approach. > >> > >>One difference is that they appear to perform permission checking on the > >>open_by_handle(), which means that the entire path needs to be encoded > >>in the handle, and makes it difficult to eliminate the path traversal > >>overhead on N open_by_handle() operations. > > > >Another (and highly important) difference is that usage is restricted to > >root: > > > >xfs_open_by_handle(...) > >... > > if (!capable(CAP_SYS_ADMIN)) > > return -XFS_ERROR(EPERM); > > I assume that this is because the implementation chose not to do the > path encoding in the handle? Because if they did, they could do full > path permission checking as part of the open_by_handle. The original use of this interface (if I understand the Irix history correctly - this is way before my time at SGI) was a userspace NFS server and so permission checks were done after the filehandle was opened and a stat could be done on the fd and mode/uid/gid could be compared to what was in the NFS request. Paths were never needed for this because everything needed could be obtained directly from the inode. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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
