On Wed, Dec 06, 2006 at 10:20:23AM -0600, Rob Ross wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html