From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chinner Subject: Re: openg and path_to_handle Date: Thu, 7 Dec 2006 08:01:16 +1100 Message-ID: <20061206210116.GE33919298@melbourne.sgi.com> References: <20061129122313.GG14315@parisc-linux.org> <20061129123913.GA15994@infradead.org> <4570ACD1.7060800@mcs.anl.gov> <4574BF52.6090600@mcs.anl.gov> <20061206094805.GB33919298@melbourne.sgi.com> <4576E783.7020402@mcs.anl.gov> <20061206204005.GC33919298@melbourne.sgi.com> <45772D29.30806@mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Chinner , Latchesar Ionkov , Christoph Hellwig , Matthew Wilcox , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from omx2-ext.sgi.com ([192.48.171.19]:40732 "EHLO omx2.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S937640AbWLFVDh (ORCPT ); Wed, 6 Dec 2006 16:03:37 -0500 To: Rob Ross Content-Disposition: inline In-Reply-To: <45772D29.30806@mcs.anl.gov> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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