At 9:30 -0700 00/06/27, Karp, Alan wrote:
>When we were designing e-speak access control we worried about the
>scalability of our system. Conventional capabilities weren't going to do
>the trick. (Actually, we learned about capabilities after having reinvented
>them "wrong", but it's the "wrong" part that's interesting.) A conventional
>capability contains, among other things, a handle for the object being
>controlled and the access rights the presenter of the capability will be
>granted.
>
>The problem is the number of capabilities I need to deal with. After all,
>my PC has over 60,000 files on it. In the most general case, I need a
>conventional capability for each operation, e.g., read, write, execute, for
>each file. Some applications, SAP comes to mind, have hundreds or thousands
>of methods, each of which I might want to control separately. The number of
>capabilities to be managed becomes a problem quite quickly.
>
In most capability systems the various capabilities to some particular
object need not be created simultaneously with the object. They are created
as needed. The general pattern is that a strong capability C is returned to
the requester. Invocations of C will produce any of the forseen weaker
capabilities. Even capabilities with access discrimination unforseen when
code for the object was written can be provided by writing a "front end"
object which holds a strong capability to the real object and filters
messages to the real object. A capability to the front end is like a
capability to the original object with the new rule in place. For instance
a data base can be front ended with a noise function that smears but does
not hide statictical properties of the salary field of personel records.
....
Norman Hardy <http://www.mediacity.com/~norm>