<html>
<body>
At 07:15 AM 10/3/2007, Matheus Morais wrote:<br><br>
<blockquote type=cite class=cite cite="">On 10/3/07, <b>Kevin Reid</b>
<<a href="mailto:kpreid@mac.com">kpreid@mac.com</a>> wrote:
<dl>
<dd>This is inconsistent. Randomly generated values are only useful if
<dd>you're creating sparse capabilities (those which the client can
<dd>access the bits of); but the presence of the r_list means that these
<dd>must be protected capabilities (those which the client can't access
<dd>the bits of, or at least can't cause a given bit-sequence to be used
<dd>as a capability).<br>
<dd>Assuming that you intend protected capabilities (which have superior
<dd>properties), there is no reason for the "key" to be random;
it might
<dd>as well be a pointer or index referring to the implementation of the
<dd>capability (what is invoked/accessed when the capability is
used).<br><br>
</dl><br>
Yes your assumption are correct, I'm wanted to create a protected
capabilitie environment. Well, now I'm a bit lost, the key is the
identifier to point for an object which has that capabilitie or for what
_action_ that capabilitie could provide to the object? I was thinking in
that manner, the key is used to identify what object that capabilitie is
assigned to and the r_list will provide what permissions are given by
that capabilitie. For example, when a program P call to write in a file
F, the system will check in P's capability list if the key pointed to F
exists and then look what actions(r_list) will be available to P over F.
</blockquote><br>
To my thinking you are focusing too much on implementation<br>
details.<br><br>
I believe the base idea of a capability is a parameter<br>
token that can communicate permission to a designated<br>
something (an object) between two protected domains<br>
(vats, processes, etc.) so as to preserve their possible<br>
mutually suspicious interaction.<br><br>
The strongest forms of capability implementation include<br>
the permission to communicate to whatever services<br>
requests on the object with the communicated capability.<br>
Such forms support the confinement property.<br><br>
Beyond the above it seems to me you start to delve into<br>
implementation details - which we on this list of<br>
course love to debate endlessly. You will find such<br>
a huge variety of successful implementations of the<br>
capability concept that I hope you don't try to define<br>
the concept by any particular implementation or even<br>
type of implementation - hardware, software, protected<br>
references, capabilities as data, etc.<br><br>
You can find efforts to describe capabilities that<br>
have been hashed to some extent on Wikipedia, e.g.:<br><br>
<a href="http://en.wikipedia.org/wiki/Capability-based_security" eudora="autourl">
http://en.wikipedia.org/wiki/Capability-based_security<br>
</a>
<a href="http://en.wikipedia.org/wiki/Object-capability_model" eudora="autourl">
http://en.wikipedia.org/wiki/Object-capability_model<br><br>
</a>While I naturally have my own opinions that differ some<br>
(since I didn't write the above ;-), I particularly<br>
recommend the beginning of the second reference which<br>
I believe focuses on the essence of the capability concept.<br>
<x-sigsep><p></x-sigsep>
--Jed
<a href="http://www.webstart.com/jed-signature.html" eudora="autourl">
http://www.webstart.com/jed-signature.html</a> </body>
</html>