Christoph Hellwig wrote:
quoted text
> 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()).

quoted text
> 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.

quoted text
>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html