[cap-talk] The Hurd and Capabilities

[Jed Donnelley]

At 09:10 AM 8/11/2006, Neal H. Walfield wrote:
>...
>Mach ports are kernel objects named by protected capabilities,
>i.e. capability names are local to a C-space.  They can only be
>transferred as part of a message's payload.

That sounds positive.  I have to admit that I only looked moderately
closely at Mach ports in the middle and late 1980s, partly to check out
what was essentially a republication of the mechanisms in the DCCS on
top of Mach ports.  I've forgotten many of the details.

Regarding Mach though, let me create some context as I see it.

We've seen capabilities discussed (e.g. on this list) and implemented
at what I believe are three distinct levels, language (I'll refer to as "low"
level), OS (I'll refer to as "mid" level), and network (I'll refer to as
"high" level).  The Mach implementation seems to fall into the mid
category.

I've been advocating on this list mostly for a top down spread of
capabilities - that is from the network (e.g. YURLs, widewords)
down.  Other approaches are from the low (language) level up
and from the mid (OS) level up and down.

In this regard I'd like to consider Mach and it's possible role in
the spread of object capabilities from the mid level up and down.

Let me ask it this way - why wasn't EROS built on a Mach
kernel or using a Mach kernel?  Most of the references I see
seem to suggest that this was mostly a performance issue,
e.g. "EROS: a fast capability system" by Shapiro, Smith, and
Farber.  Is performance really such a serious issue with Mach?
Is there anything about the functioning of Mach's basic capability
architecture that's problematic (e.g. can't be extended, impossible
to proxy)?  We seem to have Mach underlying MacOS (still
true to some extent?) and the Hurd, might there be an opportunity
to extend Mach ports to the general object capability model
and spread them?  Perhaps connect them with YURLs at
the network level and with OO "objects" (e.g. in E, others)
at the language level?

> > > > Is there a general summary of capabilities in the Hurd somewhere?
>
>Marcus and I are working on a paper and I wanted to clarify the
>meaning of facets.

I look forward to reading it.

> > Or even create their own groups!!!  That's one aspect of Unix access
> > control that's so absurd to me that I can't understand why the world
> > doesn't scream about it.  If you have a simple mechanism for bags
> > of named capabilities (object access/references), a "directory", then
> > you naturally get a directed graph mechanism that can be used
> > quite effectively for general sharing.  "Group" sharing is accomplished
> > by creating a directory, giving it to others, and then putting shared
> > objects (capabilities) into it (e.g. see:
> >
> > https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D
> >
> > ).
>
>Although we don't have such a mechanism currently available, I think
>it would be quite easy to implement this.  Indeed, I think it is for
>the most part just a "natural" use of the Hurd mechanisms.
>
>But I think you could approximate this on Unix as well using
>cryptographic hashes.  Create a directory without read permission
>(e.g. foo) and place in it one directory for each group with a secure
>name (e.g. foo/45adf8uasdflkj).  Give the path name to these
>directories to those with whom you want to share.

Interesting thought.  The term "hack" comes to mind.  Still,
pursuing it a bit, then I guess one would be forced to put any
objects (e.g. limit to files and directories at this point) that
one wished to be able to share (delegate) into such a hashed
directory?  I suppose one could imagine hard links to files
elsewhere in a Unix directory structure being placed in
such hash protected directories.  Of course it would take
some sort of setuid root program to place such hard links,
with all the awkwardness for lost objects (inevitable in a
network directed graph directory structure), etc., but I
could imagine it working.  Does anybody consider such an
approach viable?

> > >The question the Hurd designers tried to answer was:
> > >how can we eliminate the inconvenient policies from the mechanisms?
> > >Fine grained objects and virtualizable interfaces were the answer they
> > >came up with.
> >
> > Sounds perfect.  Then if you can communicate access to such
> > objects (permission to access an object, a "capability" to the object)
> > then you have the capability model.
> >
> > For me the main issue is how such an underlying mechanism bubbles
> > up to the human user through all the libraries and especially the
> > applications and their built on Unix orientation.  (I appreciate
> > the cap desk contribution...).
>
>We use a "fat" C library.  The POSIX mechanisms are built on top of
>Mach and Hurd mechanisms.  Many applications don't need to be modified
>at all to take advantage of most of the relevant Hurd features, e.g.
>the C library transparently wraps the VFS.  Applications can be
>modified to take advantage of Hurd features.  Because POSIX is just a
>thin layer, this can often be done with little effort.  To get access
>to additional Hurd features, there are a number of utilty programs for
>e.g. attaching a file system to the VFS.

This sounds very much like the sort of structure we had in NLTSS.
For us it was "baselib" instead of the "fat" glibc.  Normal previous
applications ran fine and new features were available.  The problem
was that there was no way to get off "ground zero".  The basic
program paradigm was still "ambient authority".  Programs assumed
they had access to a directory with access to all the users
permissions.  From the viewpoint of both people (users) and
applications that were developed in the past and continued to
be developed, the model was old OS (in the Hurd case Unix,
Unix file access controls, groups, the whole Unix/Posix thing).

Is there some way to avoid that bind or at least some path to
get past it with the Hurd on the Mach kernel?  For example, could
something like cap desk be implemented on the Hurd and make
more direct use of the Hurd's (Mach's) capabilities (ports)?

Thanks for the update Neal.  Look forward to the paper.

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