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) > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
