From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: openg and path_to_handle Date: Thu, 14 Dec 2006 16:52:50 -0600 Message-ID: <4581D5C2.3010402@mcs.anl.gov> References: <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> <20061206220910.GJ5937@schatzie.adilger.int> <20061206233925.GA7540@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Wilcox , David Chinner , Latchesar Ionkov , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:38145 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750728AbWLNWw7 (ORCPT ); Thu, 14 Dec 2006 17:52:59 -0500 To: Christoph Hellwig In-Reply-To: <20061206233925.GA7540@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Christoph Hellwig wrote: > On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote: >>> 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. >> If the server has to have processed a real "open" request, say within >> the preceding 30s, then it would have a handle for openfh() to match >> against. If the server reboots, or a client tries to construct a new >> handle from scratch, or even tries to use the handle after the file is >> closed then the handle would be invalid. >> >> It isn't just an encoding for "open-by-inum", but rather a handle that >> references some just-created open file handle on the server. That the >> handle might contain the UID/GID is mostly irrelevant - either the >> process + network is trusted to pass the handle around without snooping, >> or a malicious client which intercepts the handle can spoof the UID/GID >> just as easily. Make the handle sufficiently large to avoid guessing >> and it is "secure enough" until the whole filesystem is using kerberos >> to avoid any number of other client/user spoofing attacks. > > That would be fine as long as the file handle would be a kernel-level > concept. The issue here is that they intent to make the whole filehandle > userspace visible, for example to pass it around via mpi. As soon as > an untrused user can tamper with the file descriptor we're in trouble. I guess it could reference some "just-created open file handle" on the server, if the server tracks that sort of thing. Or it could be a capability, as mentioned previously. So it isn't necessary to tie this to an open, but I think that would be a reasonable underlying implementation for a file system that tracks opens. If clients can survive a server reboot without a remount, then even this implementation should continue to operate if a server were rebooted, because the open file context would be reconstructed. If capabilities were being employed, we could likewise survive a server reboot. But this issue of server reboots isn't that critical -- the use case has the handle being reused relatively quickly after the initial openg(), and clients have a clean fallback in the event that the handle is no longer valid -- just use open(). Visibility of the handle to a user does not imply that the user can effectively tamper with the handle. A cryptographically secure one-way hash of the data, stored in the handle itself, would allow servers to verify that the handle wasn't tampered with, or that the client just made up a handle from scratch. The server managing the metadata for that file would not need to share its nonce with other servers, assuming that single servers are responsible for particular files. Regards, Rob