Re: openg and path_to_handle

[David Chinner <dgc@sgi.com>]

On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
> David Chinner wrote:
> >On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
> >>On 12/5/06, Rob Ross <rross@mcs.anl.gov> wrote:
> >>>Hi,
> >>>
> >>>I agree that it is not feasible to add new system calls every time
> >>>somebody has a problem, and we don't take adding system calls lightly.
> >>>However, in this case we're talking about an entire *community* of people
> >>>(high-end computing), not just one or two people. Of course it may still
> >>>be the case that that community is not important enough to justify the
> >>>addition of system calls; that's obviously not my call to make!
> >>I have the feeling that openg stuff is rushed without looking into all
> >>solutions, that don't require changes to the current interface.
> >
> >I also get the feeling that interfaces that already do this open-by-handle
> >stuff haven't been explored either.
> >
> >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).
> >
> >See:
> >
> >http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man3/open_by_handle.3.html&srch=open_by_handle
> >
> >For the libhandle man page. Basically:
> >
> >openg == path_to_handle sutoc == open_by_handle
> >
> >And here for the userspace code:
> >
> >http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libhandle/
> >
> >Cheers,
> >
> >Dave.
> 
> 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.

open_by_handle() is checking the inode flags for things like
immutibility and whether the inode is writable to determine if the
open mode is valid given these flags. It's not actually checking
permissions. IOWs, open_by_handle() has the same overhead as NFS
filehandle to inode translation; i.e. no path traversal on open.

Permission checks are done on the path_to_handle(), so in reality
only root or CAP_SYS_ADMIN users can currently use the
open_by_handle interface because of this lack of checking. Given
that our current users of this interface need root permissions to do
other things (data migration), this has never been an issue.

This is an implementation detail - it is possible that file handle,
being opaque, could encode a UID/GID of the user that constructed
the handle and then allow any process with the same UID/GID to use
open_by_handle() on that handle. (I think hch has already pointed
this out.)

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group