On Wed, Dec 06, 2006 at 02:50:49PM -0600, Rob Ross wrote:
quoted text
> David Chinner 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.
> >
> >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.)
> 
> Thanks for the clarification Dave. So I take it that you would be 
> interested in this type of functionality then?

Not really - just trying to help by pointing out something no-one
seemed to know about....

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