[cap-talk] 'Mask' (sensory, inheritance, Norm) - c2
Jed Donnelley
JEDonnelley at lbl.gov
Fri Aug 17 19:10:28 EDT 2007
----- Original Message -----
From: "Karp, Alan H" <alan.karp at hp.com>
Date: Friday, August 17, 2007 2:32 pm
Subject: Re: [cap-talk] 'Mask' (sensory, inheritance, Norm)
To: "General discussions concerning capability systems." <cap-talk at mail.eros-os.org>
> Alan Grover wrote:
> >
> > Richard Kulisz[2] (on c2.com wiki) seems to have a solution which he
> > calls "General Capability Model"
>
> Aside from the name, I don't see what this scheme has to do with
> capabilities. The fundamental aspect of a capability is that it
> combines designation with authorization. Kulisz says, "So if you
> have a
> delete permission set then this means that you have permission to
> deletethat capability (assuming you can get a message through to
> it)." That
> doesn't sound like a capability to me.
Hmmm. I'm not so sure the mechanisms described in:
http://c2.com/cgi/wiki?GeneralCapabilityModel
don't qualify in some sense as a "capability" model, though I
admit that there is a good deal there that I don't think I am
understanding. For example, the part about 'links' (capabilities?)
being bidirectional:
__________________
Another important concept is that all links are bidirectional. This means that all capabilities are paired up. Why do you care that they're paired up? So that the user who gave you a capability to an object can revoke it. This isn't necessary in theory because you can use a capability security model where the caps you hand out are only valid for a limited period of time. But of course, that doesn't make sense in practice. In practice, it's necessary for people to be able to see the caps they handed out and revoke them as necessary. So how do you ensure that they're actually paired up? That's really simple. You implement a subscriber model where any caps that aren't properly paired up don't see any updates to the object they point to. So if object A doesn't have a cap to object B which contains a cap to object A, then when object A gets updated, it won't update the cap pointing back to itself. Really simple, and necessary besides.
__________________
Simple? Doesn't sound so 'simple' to me.
I wonder if we (perhaps I?) should try to engage Richard Kulisz
on this 'deep attenuation' topic - e.g. interactively and verbally
to begin with - to see if there is any productive cross fertilization
that can help?
Certainly the Horton mechanism is providing some of the
values that he seems to be looking for. How he intends
to get everything he describes might be an interesting story.
--JED http://www.nersc.gov/~jed/
More information about the cap-talk
mailing list