[cap-talk] Core of IBAC dominance - direction? (was: Re: Confused Deputies in Capability Systems - not)
toby.murray at comlab.ox.ac.uk
Mon Mar 2 04:27:08 EST 2009
On Sun, 2009-03-01 at 17:51 -0800, Jed Donnelley wrote:
> What I haven't yet seen for such network capabilities as data is a
> mechanism for making the objects they point to available as
> semantically equivalent objects in existing systems, e.g. Unix
> and/or Windows. As perhaps with a mechanism to "mount" a
> networked directory capability with the ability to inject (import?)
> such files and/or directories into a local structure - providing
> the ability to apply local tools to them (e.g. players for
> viewing, editors for file manipulation, listing for directories,
> etc.). It seems that effective caching and locking would be needed.
> Of course there would be (are? Are there such mechanisms available?)
> conflicts in the area of access control, but that's to be expected
> without agreement on IDs.
Have a look at Tahoe and its FUSE plugins. With Tahoe, you can mount a
remote (distributed) filesystem using a capability-as-datum (i.e.
password capability, if you like) that you pass to the 'mount' command.
You can then interact with the filesystem as if it were any other remote
filesytem (e.g. NFS) as usual. If you want to delegate a subtree to
someone, you can get the capability-as-datum for that subtree (or a
transitively-read-only version) and then pass on the datum. Whoever you
give it to can then access just that subtree either by mounting it or by
using a web interface or any of the other Tahoe frontends.
What Tahoe lacks from your requirements it the ability to host
'arbitrary' objects. It is "just" a filesystem.
More information about the cap-talk