[cap-talk] Deep attenuation, typed operations

[Jed Donnelley]

----- Original Message -----
From: Charles Landau <clandau at macslab.com>
Date: Tuesday, August 14, 2007 10:39 am
Subject: Re: [cap-talk] Deep attenuation, typed operations
To: jed at nersc.gov, "General discussions concerning capability systems." <cap-talk at mail.eros-os.org>

> At 9:01 PM -0700 8/13/07, Jed Donnelley wrote:
> >A variation on this theme that I've considered is
> >one in which the permitted operations are
> >typed.  That is, each operation is listed with
> >a type, like [insert,directory] noting that the
> >"insert" operation will be explicitly allowed
> >when the "allow-only" operation is performed
> >on a returned object of type 'directory'.
> 
> 1. This seems like a lot of responsibility to place on the 
> directory, 
> and a lot of state to remember.
> 
> 2. Types have limitations. Suppose you have a directory with [read, 
> file] as its deep attenuation rule. Now I create an object of type 
> newFile that also has read and write operations. (The type is 
> newFile, not file, because it has other differences from the file 
> object.) Using my unattenuated capability to a subdirectory, I put 
> a 
> cap to the newFile in the subdirectory. Given that the type of my 
> object is different from file, there is no way I can permit you to 
> get a read-only capability to my object.

Thanks for considering the alternative mechanisms.

At least as I intended things (perhaps not explained well?),
there is a way to share a read-only capability to your
object of type newFile.  Namely just add the 'permission'
[read,newFile] to the directory and  no others of the form
[*,newFile].  Indeed it was this additional flexibility that
suggested this extended sort of 'deep attenuation'
facility to me.

Did you imagine the mechanism differently?

The way this extended mechanism works is
that when a capability, c, of time sendType is
being sent out from a server that supports
the 'deep attenuation' property and that property
is turned on in a capability (say, b, being invoked
and returning the capability c), then the server
does a returncap = c.AllowOnly([permissions]
where permissions are the projection of
the [*,*] typed permissions on the sendType.
Namely, only the permissions of the type
sendType in the permission set of the
capability being fetched through (say, b)
will be allowed in the resultant returned
capability.

I believe this is a more general and more
flexible mechanism.  It suffers from the
fact that types must be available to it and
from the fact that all permissions
for all returned types must be included
in the permission set of the type sending
the message (lest they have all their
access permissions removed).  To
me those seem relatively small
disadvantages for it's additional
flexibility.

Now that I think of it, it seems this more
general mechanism could provide the
less flexible mechanism simply by allowing
types of the form [permission,*] in the
permission set.  One could imagine
extensions of the usual sort, e.g.
[permission, allbut oneType, twoType],
etc.

With such an extension I see pretty
much only advantages to this more
flexible mechanism.  If there is some
sort of consistent use of common
permissions across types (e.g.
a common "read" permission), then
it can be permitted deeply as [read,*].
If there is no such commonality for
multiple types, then the permissions
intended to be allowed can be explicitly
specified.

Of course the above expression approach
would also allow permission sets like
[allbut directory, allbut insert] to request
that only the 'insert' permission be
turned off from returned capabilities
to objects of type directory - as dangerous
as that might seem.

I definitely think this approach that uses
[permission,type] pairs in the set to be
used for the allow-only operation is more
flexible without loss of generality.

Did I fail to explain it adequately or perhaps
there is something that I am still missing
about it?

--JED  http://www.nersc.gov/~jed/