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:09:37 +1100 Message-ID: <20061206210937.GF33919298@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> <20061206205023.GD3013@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Chinner , Rob Ross , Latchesar Ionkov , Christoph Hellwig , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from omx2-ext.sgi.com ([192.48.171.19]:40901 "EHLO omx2.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S937643AbWLFVJ7 (ORCPT ); Wed, 6 Dec 2006 16:09:59 -0500 To: Matthew Wilcox Content-Disposition: inline In-Reply-To: <20061206205023.GD3013@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Dec 06, 2006 at 01:50:24PM -0700, Matthew Wilcox wrote: > On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote: > > 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.) > > While it could do that, I'd be interested to see how you'd construct > the handle such that it's immune to a malicious user tampering with it, > or saving it across a reboot, or constructing one from scratch. > > I suspect any real answer to this would have to involve cryptographical > techniques (say, creating a secure hash of the information plus a > boot-time generated nonce). Now you're starting to use a lot of bits, > and compute time, and you'll need to be sure to keep the nonce secret. An auth header and GSS-API integration would probably be the way to go here if you really care. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group