[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Confused Deputy (definitions), capabilities and  Unix
From:       "Neal H. Walfield" <neal () walfield ! org>
Date:       2006-10-31 23:52:27
Message-ID: 87ac3c9h6s.wl () plato ! walfield ! org
[Download RAW message or body]

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 [1].
The version of Mach that we use does not support exporting kernel
state.

> 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
usability?

Thanks,
Neal


[1] User-level Checkpointing through Exportable Kernel State, Patrick
Tullmann, Jay Lepreau, Bryan Ford, Mike Hibler.

[2] Reflections on an operating system design, Butler W. Lampson,
Howard E. Sturgis.
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]