[cap-talk] Unestos paper notes (was: Re: More Heresey: ACLs not inherently bad)

[Toby Murray]

On Sun, 2008-08-31 at 14:20 -0700, Jed Donnelley wrote:
> Is there any evidence that 'capabilities have flummoxed application
> designers'?

If I said to you "pure functional programming flummoxes [some]
application programmers", would you object?

Capabilities need not be inherently more difficult to understand than
conventional Unix semantics in order to "flummox application designers",
but merely be less widely employed.

However, like with pure functional programming, a case can be made that
capabilities are difficult to understand for those who are used to the
more traditional approach, just as pure functional programming can be
difficult to understand to many of those coming from an imperative
programming background.

Further, many of the useful idioms of capability-based design have only
recently matured or had their visibility increase to the point that they
are understood by more than a handful of people (e.g. the ubiquitous
powerbox abstraction, membranes etc.). c.f. the notion of monads in pure
functional programming which have only been popularised in the last 15
years or so.

There is every reason to suspect that capabilities do flummox
application designers. This doesn't mean that they are harder to
understand but could merely be a symptom of their unfamiliarity or of
the relative immaturity of capability-based design. 

Finally, capabilities need not even be unfamiliar nor capability-based
design need be relatively immature for capabilities to be harder to
understand but merely *appear* that way.

> 6.  This section of the paper under 3.2 "Naming and Managing
> Capabilities" puzzles me somewhat:
> 
> "...Traditional capability systems such as EROS favor global,
> persistent naming, but persistence has proven cumbersome to kernel and
> application designers [27]."
> 
> Is the above true?  Isn't it the persistence of active elements
> (processes, active objects) that have proves "cumbersome" (actually a
> tradeoff)?  I haven't heard of any cumbersome aspects of persistent
> naming of objects.

Note that they say only that "persistence" is cumbersome. The initial
motivation to drop persistence for Coyotos suggests that it indeed can
be, although I might be misrepresenting the situation here.


>   They continue:
> 
> "Instead, we advocate a per-process, Unix-style namespace. Under
> Unestos, P1 makes capabilities available to P2 as files in P2s
> namespace. Suppose P1s namespace contains a tree of files and
> directories under /secret, and P1 wishes to grant P2 access to files
> under /secret/bob. As in Plan 9 [20], P1 can mount /secret/bob as the
> directory /home in P2s namespace.  Unlike in Plan 9, the state
> implicit in the perprocess namespace is handled at user level, and the
> kernel only traffics in messages sent to capabilities. For example,
> when the process P2 opens a file under /home, the user level libraries
> translate the directory /home to some capability C.  The kernel sees a
> LOOKUP message on C."
> 
> I don't understand what is going on in the above.  Are they advocating
> that the kernel support separate Unix-style name spaces for each
> process?

Yes, I believe so.

>   When they suggest that P1 'mount' /secret/bob as the directory /home
> in P2's name space it seems to me they are overreaching a bit.  Why
> should P1 control names in P2's environment.  To me it seems more
> effective for P1 to simply send a "capability" to /secret/bob to P2.
> P2 can "mount" it anywhere it wishes.

Sure, but the traditional UNIX API has no means to represent such a
capability. There needs to be some sort of "handle" that the application
can use to refer to the capability. They've chosen to use filenames for
that purpose.

> 
> 
> 7.  Regarding 3.3 "OKWS Under Unestos", it seems to me that OKWS under
> a simple OCap system is even simpler.

Could you sketch it out so we can compare? Even if it were simpler, the
OKWS design in the paper has the advantage that it is relatively
familiar to those used to building POLA applications on UNIX (e.g. qmail
is an obvious example).

> 
> 
> 8.  Regarding "4 FINE-GRAINED POLP WITH MAC":

I'm not convinced of the need for this part (MAC) either. That's why I
referred only to Unestos and not Asbestos when bringing this up.

Cheers

Toby