[cap-talk] Deep attenuation

[David Hopwood]

Jed Donnelley wrote:
> cap-talk,
> 
> I'm reaching out for help refining and naming a mechanism
> that has been around in capability systems for some time.
[...]
> In the old Livermore Elephant system this mechanism
> was called "inheritance" (before that term was adopted
> for OO).  In the NLTSS system we flipped the sense of
> it and referred to it as "free access".  MarkM indicated
> that something similar was used in KeyKOS I believe
> referred to as "sensory" (?).
> 
> The basic idea is to have a mechanism for
> "attenuating" (reducing permissions conveyed
> by) capabilities fetched through other capabilities.
> When we were thinking of names in Boston MarkM
> came up with "deep attenuation".  In thinking about
> it now I think I like the term "Mask" (for reasons
> explained below) for this property of a capability.

I prefer "deep attenuation", since that is consistent with
the shallow version being called just "attenuation".
"Mask" does not convey the idea that the attenuation
applies transitively to referenced objects.

> It's because of this difference between
> a property and a stricter permission that
> I don't feel compelled to flip the sense
> of this property as we did in NLTSS.

If implemented using a bit in the capability representation,
it doesn't matter what the sense of that bit is. The most
common, 'unmarked' case is that of no attenuation, and so the
name should apply to the other, 'marked' case.

> B.  What do people think about such a
> mechanism?  Is something like it needed
> at all?

Yes, it is a frequently needed pattern. In particular, whenever
you have user-level "objects" being represented as networks of
fine-grained objects at the capability system level, a user's
idea of a 'read-only' authority is captured better by deep
attenuation than by shallow attenuation. So if deep attenuation
were never used, that would effectively limit how fine-grained
objects could be.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>