[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