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

[Jed Donnelley]

At 01:27 AM 9/1/2008, Toby Murray wrote:
>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...

I appreciate this argument.  However, I've seen programmers deal with
so many different and even awkward situations (in which class I don't
consider OCap programming) without suggesting that they are "flummoxed"
that it surprises me to hear that word used by anybody who actually
did capability or strict object programming.  Perhaps I just have a
higher standard for flummoxing programmers.

I'd like to hear more about the programmers who were actually so
flummoxed and the situations they found awkward.

> > 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.

The way I read the quote it was referring to persistent naming, not
to persistence in general - i.e. active object (process) persistence.
I understand the issues with persistence in general.  There are
also some issues with persistent naming, but I believe systems like
Unix share those issues.  Perhaps I didn't understand what he was
getting at.

> >   They continue:
> >
> > "Instead, we advocate a per-process, Unix-style namespace...
> >
> > 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.

That seems a bit heavy handed to me.  I don't see what value it
adds beyond a per directory flat name space.  With a per directory
flat name space one can create a hierarchical "Unix-style" name space
with the use of multiple directories with what to me seem fewer issues
with mechanisms like "mounting".

> >   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.

I thought the file descriptor served as such a capability.  It seems
to me a small matter to support "directory descriptors" along the
same lines that support fetch, insert, and delete in addition to
read and write.

>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.

Again I thought they used file descriptors for that purpose.  It's
file descriptors that they allow to pass through pipes.  File names
can of course also be passed through pipes, but as designation only.

> > 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).

I'll have to see if I can revisit the paper and pursue this later
as I have a commitment at the moment.  I don't recall reading about
any mechanism for the OKWS design in the paper, just a reference to
it, so I'm not quite sure how I can do such a comparative sketch,
but I'll give it a crack.

> > 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.

Do you believe that when they say 'MAC' in this paper they mean more than
what we typically refer to as 'confinement'?  From my read of the paper it
wasn't clear.

--Jed  http://www.webstart.com/jed-signature.html