Re: openg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux