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
