[cap-talk] keyrings and bootstrapping capabilities

[Jed Donnelley]

At 08:23 PM 5/28/2007, Norman Hardy wrote:

>On 2007 May 28, at 4:37 PM, Jed Donnelley wrote:
>
> > At 12:40 PM 5/28/2007, Norman Hardy wrote:
> >> Thanks Jed for the additional background.
> >>
> >> On 2007 May 28, at 12:25 AM, Jed Donnelley wrote:
> >> ........
> >>> If, however, one is given access to a directory without
> >>> the "free access" right, then all access rights that are
> >>> turned off in the directory capability itself are turned
> >>> off in the fetched capabilities before being returned
> >>> in response to "fetch" requests.
> >>>
> >> Of what use is such a returned capability?
> >> Perhaps rights amplification was necessary to use it.
> >> Keykos did not use this pattern but the kernel could support it.
> >>
> >> ......
>
>......
> >
> > Remember the idea?  I'm sure we've discussed it on the cap-talk
> > list before.  I believe I've seen this ideal elsewhere, but not
> > before it was done in the Elephant storage system circa 1970.
> > This seems to be another one of those ideas that has been
> > invented more than once.
>
>Yes, This pattern occurs in Keykos when a sensory key to a node is
>invoked to fetch a capability therein.
>The kernel understands nodes for it responds to invocations thereof.
>It understands pages and that RW page keys can change the page.
>If there is a RW page key in the node and the holder of the sensory
>key does a fetch for that key, then the RO key to the same page is
>returned.
>If node A holds a node key to node B and X fetches that key by
>invoking a sensory key to A, The X gets back a sensory key to node B.
>Thus the kernel supports perusing a tree of nodes starting with a
>sensory key to the top node.
>These actions cannot lead to modification of anything in the tree.

That sounds like a kernel specific operation on just the sensory key.
Regarding:

>There was no such kernel facility for the directory because the
>kernel was not directory savvy.
>The directory was an ordinary object implemented in user code,
>outside the ken of the kernel

In the Elephant system and certainly in NLTSS the directory
server was also outside the kernel.  No special kernel
privileges were needed.  All it amounted to was a "hack"
on access bits that depending on conventions for the bits.
When a fetch request was done to the directory server, if
the "free access" permission was set, then no problem, it
just returned the fetched capability (like a bag of named
capabilities).

However, if the "free access" bit wasn't set, then the directory
server would look at the permission bits that were turned off
in the directory capability (including of course the "free access"
bit itself) and make a request of whatever capability was being
fetched to turn off the corresponding bits.  Of course this
mechanism also depended on there being a 'standard' call to
reduce the access permissions of a capability.

This mechanism worked well for files and directories, but I don't
recall any other practical applications.

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