From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: openg and path_to_handle Date: Wed, 06 Dec 2006 14:50:49 -0600 Message-ID: <45772D29.30806@mcs.anl.gov> References: <20061128055428.GA29891@infradead.org> <20061129090450.GA16296@infradead.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Latchesar Ionkov , Christoph Hellwig , Matthew Wilcox , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:50650 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937633AbWLFUzz (ORCPT ); Wed, 6 Dec 2006 15:55:55 -0500 To: David Chinner In-Reply-To: <20061206204005.GC33919298@melbourne.sgi.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org David Chinner wrote: > 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 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. Thanks for the clarification Dave. So I take it that you would be interested in this type of functionality then? Regards, Rob