[cap-talk] Capability-based Projects - theory vs. practice

[Jonathan S. Shapiro]

On Thu, 2007-08-02 at 11:59 -0700, Jed Donnelley wrote:
> Jonathan S. Shapiro wrote: 
> > Actually, I don't consider Mach a capability system either.
> > 
> > One issue is that the unit named by descriptors in both systems is the
> > server, not the object implemented by the server.
    
> Hmmm.  It's been a long time since I looked into this aspect of these
> systems in detail, but as I recall this may (?) end up being more
> a quantitative distinction than a qualitative distinction?
> 
> It's certainly true that Mach (and I believe DEMOS at least
> falls into the same category, perhaps Chorus?) referred to
> their protected objects as "port"s.  This suggests more of
> a "network address" sort of use...

You are correct. A mach thread may have many receive ports, enabling it
to use ports to name objects. Further, it can aggregate these into sets
so that it can do "receive on any" operations.

However, Mach is at best an impure capability system. There exist system
calls other than "invoke capability", and the Mach documentation is very
careful to characterize it as "capability-like" (their term).

My impression from a quick review of the Chorus docs is that Chorus
ports name processes. A chorus "capability" (unprotected, though they
thought otherwise) names a port and gives an object ID.

It is not clear how the Chorus "capability" notion corresponds to
capabilities, and it might be good to check before engendering
confusion.

> Perhaps what is more important for such systems is
> how they use their protected objects in practice.
> I often use the file system as an important test case.
> Does Mach (DEMOS, Chorus?) use separate "port"s
> for each file or do they somehow use a smaller number
> of ports and include designation information as data?

I suspect so, but more importantly: Mach uses principal-based access
control, because ports do not survive system restart. Chorus likewise.



shap