On Wed, Dec 06, 2006 at 02:50:49PM -0600, Rob Ross wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
