On Wed, Dec 06, 2006 at 09:42:47AM -0600, Rob Ross wrote:
quoted text
> 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)

quoted text
> There is state here, clearly. I feel ok about that because we allow 
> servers to forget that they handed out these fh_ts if they feel like it; 
> there is no guaranteed lifetime in the current proposal. This allows 
> servers to come and go without needing to persistently store these. 
> Likewise, clients can forget them with no real penalty.

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.

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.

-
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