[cap-talk] Deep attenuation, typed operations

[Jed Donnelley]

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

> At 9:22 PM -0700 8/14/07, Jed Donnelley wrote:
> >----- Original Message -----
> >From: Charles Landau <clandau at macslab.com>
> >Date: Tuesday, August 14, 2007 10:39 am
> >
> >  > 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.
> 
> I don't have a capability to the top directory, only to the 
> subdirectory, so I can't add [read,newFile] to the top directory. 
> You 
> have a capability to the top directory, but you don't know about 
> newFile, so you don't know to add it.

If I don't know about object types and their operations that may
be present deep in the structure, then the default mechanism
'fails' soft - that it it denies any unknown operations.

However, with the extension that I mentioned in my last
message (wild cards, albut. etc.) one can certainly include
[read,*] to get the same effect.

> When I said "types have limitations", I meant that they don't 
> capture 
> all the polymorphisms of an object - i.e. the fact that newFile 
> implements read just as file does. I don't think we want to make it 
> easy for people to thwart polymorphism. It seems like what you 
> really 
> want is [read, file and all other types that are polymorphic with 
> file including types that haven't been invented yet]. I don't know 
> how to implement that.

As far as I know a type, e.g. "file", is just a name.  In that case
it seems to me that it suffices for any polymorphic implementation
of a 'file' type to use the same name.

This suggests of course an easy mechanism to 'escape' deep
attenuation - namely create an object that says it is a 'polymorphic'
type for an existing type with a permission overloaded to an
existing permission that is allowed deeply.  I consider this a
feature and not a bug.  That is, the intent of the deep attenuation
mechanism is to make available restricted access to objects
of know types of good and useful services.  If you have instances
of types that are not trustworthy (not to be 'trusted'), don't
include them in your structure.  If you do include them, then
using 'deep attenuation' with them is doing what is intended.

R.e. Sam Mason's suggestion of the "reduce access" name
as an alternative to 'deep attenuation': That still has two
words, but it sounds like something that more people would
find intuitive.  For me it unfortunately sounds like a a verb
(operation).  Any other thoughts on that name?

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