From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: openg Date: Thu, 14 Dec 2006 17:36:57 -0600 Message-ID: <4581E019.8090106@mcs.anl.gov> References: <20061129090450.GA16296@infradead.org> <20061129122313.GG14315@parisc-linux.org> <20061129123913.GA15994@infradead.org> <4570ACD1.7060800@mcs.anl.gov> <4574BF52.6090600@mcs.anl.gov> <4575E83F.8090501@mcs.anl.gov> <20061206110158.GA3780@infradead.org> <4576E4F7.1040308@mcs.anl.gov> <20061206233227.GA6908@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Latchesar Ionkov , Matthew Wilcox , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:39597 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751976AbWLNXhI (ORCPT ); Thu, 14 Dec 2006 18:37:08 -0500 To: Christoph Hellwig In-Reply-To: <20061206233227.GA6908@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 09:42:47AM -0600, Rob Ross wrote: >> The fh_t is indeed a type of capability. fh_t, properly protected, could >> be passed into user space and validated by the file system when >> presented back to the file system. > > Well, there's quite a lot of papers on how to implement properly secure > capabilities. The only performant way to do it is to implement them > in kernel space or with hardware support. As soon as you pass them > to userspace the user can manipulate them, and doing a cheap enough > verification is non-trivial (e.g. it doesn't buy you anything if you > spent the time you previously spent for lookup roundtrip latency > for some expensive cryptography) I agree that if the cryptographic verification took longer than the N namespace traversals and permission checking that would occur in the other case, that this would be a silly proposal. honestly that didn't occur to me as even remotely possible, especially given that in most cases the server will be verifying the exact same handle lots of times, rather than needing to verify a large number of different handles simultaneously (in which case there's no point in using openg()/openfh()). > Objects without defined lifetime rules are not something we're very keen > on. Particularly in userspace interface they will cause all kinds of > trouble because people will expect the lifetime rules they get from their > normal filesystems. I agree that not being able to clearly define the lifetime of the handle is suboptimal. If the handle is a capability, then its lifetime would be bounded only by potential revocations of the capability, the same way an open FD might then suddenly cease to be valid. On the other hand, in Andreas' "open file handle" implementation the handle might have a shorter lifetime. We're attempting to allow for the underlying FS to implement this in the most natural way for that file system. Those mechanisms lead to different lifetimes. This would bother me quite a bit *if* it complicated the use model, but it really doesn't, particularly because less savvy users are likely to just continue to use open() anyway. >> The documentation of the calls is complicated by the way POSIX calls are >> described. We need to have a second document describing use cases also >> available, so that we can avoid misunderstandings as best we can, get >> straight to the real issues. Sorry that document wasn't available. > > The real problem is that you want to do something in a POSIX spec that > is fundamentally out of scope. POSIX .1 deals with system interfaces > on a single system. You want to specify semantics over multiple systems > in a cluster. I agree; the real problem is that POSIX .1 is being used to specify semantics over multiple systems in a cluster. But we're stuck with that. Thanks, Rob