"James A. Donald" <[email protected]> writes: > On 2011-02-02 11:04 AM, Chris Palmer wrote: > >> 1. It's a FUSE program. The end. You mount a filesystem, >> and then browse around. The UI is whatever your current >> filesystem UI is. > > Mismatch. Browsing works, but manipulation has subtle > differences.
So one can either understand the mismatches and consider if the VFS layer needs to have the concept of capabilities (and perhaps immutable/mutable file types), or reimplement an entirely new filesystem interface. I'm generally of the opinion that improving VFS for capability-type filesystems is the better approach, but then I come from a research group background. I'm also used to BSD where changing the OS seems more doable - I don't really understand why, but I run into a lot of thinking in research projects about Linux that one can add modules but that making significant permanent changes to the kernel isn't acceptable. >> 2. There are clients and there are servers. There are no >> gateways, introducers, WUI servers, helpers, et c. > > Most of these things turn up as a result of the need to > pass capabilities around. Clients and servers are only > sufficient if your client already has its capabilities. Presumably you are treating the furl to get to each server as a capability, which it is. In my usage, dir/file caps don't show up much at all on servers, just clients. > So far no one has proposed a capability system wherein > capabilities are usefully and conveniently shared between > several people, which is a serious flaw since capabilities > are most useful when you want have interactions between > several people, and administration and setup always requires > passing some capabilities around. And indeed, I scp config files around and kill/yank caps. > You always wind up needing to pass capabilities around, and the > methods for doing so always turn out to be surprising, > cumbersome, and unexpected. Typically you copy and paste a > long incomprehensible text string from some place to another > place. No one has proposed a nice clean system for passing > capabilities around, except in the vaguest and most general > fashion. Sharing capabilities is really something new in capability-based filesystems. Given the nature of tahoe caps (and I suspect in all systems where they really are capabilities), one needs confidentiality protection both in transport and at rest. So (and I'm not saying this to try to tweak James), something like a way to export a cap to a file and openpgp encrypt it to a recipient and attach it to mail would be good. Then the receipient's MUA can key off the mime type and import it into the aliases file. Of course, if there's some other transport encryption mechanism, that can be used too. As a start tahoe export-cap capfile path tahoe import-cap capfile new_alias would reduce the problem to secure file transport.
pgpB6t0ctsXGg.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
