[cap-talk] Confused Deputy (definitions), capabilities and Unix
Neal H. Walfield
neal at walfield.org
Tue Oct 31 17:52:27 CST 2006
At Thu, 26 Oct 2006 14:51:08 -0700,
Jed at Webstart wrote:
> Firstly the capabilities are not "persistent".
> That is, they disappear/become invalid when the system reboots
> (like processes). Try to imagine such permission tokens used
> in a network (even with something like the DCCS to translate
> them from system to system). I receive a capability. I do some
> work and then try to use it. It doesn't work. What happened? Oh,
> I beg your pardon. You say your system rebooted?? Mine
> didn't. Grumble.
> This non persistence of capabilities may well be inherited from
> Mach. In my opinion it simply needs to be fixed before the
> Hurd (or any other effort to "add" capabilities to Unix) could be
> taken seriously.
Some work was done to make Fluke, a successor of Mach, persistent .
The version of Mach that we use does not support exporting kernel
> I believe very strongly that the only way to make capabilities work
> effectively is to implement them as a persistent network standard.
> We can use caching techniques for local performance optimization
> if desired, but people (in addition to processes/active objects) need
> to be able to use capabilities, and people don't "reboot".
In CAL, capabilities are not persistent. Moreover, as I understand
it, directory entries are access controlled using ACLs: to gain access
to a directory entry, the caller must present a so-called access key
which appears on the ACL. [2, section 4.3].
I don't know much more about CAL other than the very abstract
information in the cited paper. Do you have more insight about its
 User-level Checkpointing through Exportable Kernel State, Patrick
Tullmann, Jay Lepreau, Bryan Ford, Mike Hibler.
 Reflections on an operating system design, Butler W. Lampson,
Howard E. Sturgis.
More information about the cap-talk