[Squeak-e] capabilities question...

[Mark S. Miller]

[cross posted to squeak-e and e-lang, as my reply isn't squeak-e specific]

At 06:16 AM 5/9/2003 Friday, Michael van der Gulik wrote:
>I'm reading that rather interesting paper about capabilities (and the myths 
>thereof) on erights.org. 

Thanks!

>I'm playing around with Squeak and researching how 
>it could be distributed using replication etc. See dpon.sourceforge.net if 
>you're interested. I may switch to E, but I'm just nosing around at the 
>moment, and reading a lot.
>
>Question: it seems quite possible to implement ACL's using capabilities. 
>Would this be true?

Yes. For example, in rehosting Unix on KeyKOS 
http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.ps.gz , Unix's 
degenerate ACL system was implemented using object-capabilities. I believe 
this also happened when rehosting CMS on KeyKOS on the IBM370. But these are 
complex examples embedded in a large context.

The Hat Racks design I propose at 
http://www.eros-os.org/pipermail/e-lang/2002-December/008107.html is built 
from object-capabilities, but is more ACL-like than object-capability-like, 
though it does leverage its object-capability underpinnings to improve on 
conventional ACL systems. For example, where ACL systems normally use human 
readable globally-scoped names, Hat Racks use first class opaque protected 
references as designators. The equivalent of a principal id is also reified 
as an opaque protected reference and explicitly wielded by the program. The 
result is much like Alan Karp's "Split Capabilities".

Hat Racks and Split Capabilities both fall in the "Capabilities as Keys" 
paradigm explained in the myths paper you're reading, with the proviso that 
both keys (as principal ids) and doors (as resource designators) are treated 
as opaque protected references. (The capabilities-as-keys paradigm as 
explained in the myths paper assumes only keys are protected.)

I am coming to believe that even in a non-legacy-burdened world of pure 
object-capabilities, there may still be a need to build some such 
capabilities-as-keys-like system from object-capabilities. (Even KeyKOS took 
a step in this direction when it introduced the CanOpener.)


>Say for example that you have a secure object called 'Secret'. Other objects 
>access 'Secret' through proxy objects. These proxy objects simply pass all 
>messages through to Secret, and can be turned on and off, to allow and 
>disallow (revoke) access to Secret.

So far, this sounds like revocable forwarders, and is a normal 
object-capability pattern.


>Now, assuming that some management system was built around this schema, each 
>proxy object is quite like an item in an Access Control List.
>
>If an authentication mechanism was also provided for subjects, which was 
>enforced by the proxies, then would there be any difference between this and 
>another implementation of an ACL system?

It all depends on the specifics of your "authentication mechanism was also 
provided for subjects, which was enforced by the proxies". Depending on the 
design, the result may or may not either be good or be ACL-like; and these 
two goals may or may not correlate as you expect.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM