[cap-talk] Can Capabilities be configured?

[Leo Meyerovich]

Relevant is our initial attempt at what we call (object) views: 
http://code.google.com/p/memblib/wiki/PaperExamples . [[Caution: this is 
not appropriate for commercial use as it needs more vetting for 
implementation bugs]]

They're membranes where the owner of the membrane can advise (or 
otherwise configure) capabilities generated with the membrane and the 
advice is automatically protected against similar attack vectors itself. 
I'm currently playing with how to get this to be natively supported, 
essentially keeping a similar abstraction but not using library-level 
wrappers (we first relied upon Caja rewriting to make wrappers safe, the 
posted version relies upon isolation through communicating over 
postMessage, the next one will be by changing the JS runtime to totally 
avoid creating new wrapper heap objects).

The ambient authority of advice question is really interesting. 
Traditional advice systems use type-based pointcuts: the ability to name 
a type (which is often global) leaks it. However, as shown in ConScript 
(a paper we did in 2010) and the 'becomes' operator in Smalltalks, 
pointcuts can be individual heap objects without much cost: to advise an 
object, you need to already have a reference to that object. Thus, 
passing an object also passes the ability to advise that object (and, if 
you don't want that to happen, pass a wrapper of that object!). Closer 
to traditional languages where passing a reference does not imply 
passing that ability, with our object views (as released), a reference 
to an object and the membrane controller is required to change the 
behavior of the corresponding view of that object, but won't change the 
base object itself. I believe  Gilad Bracha is facing similar to 
questions with his Mirrors proposal (which is gaining momentum within 
the JS community): 
http://gbracha.blogspot.com/2010/03/through-looking-glass-darkly.html .

So: how do we avoid ambient authority when mixing advice and 
metaprogramming with ocaps? Should individual objects have their own 
associated advice/metaprogramming functions that can be removed, or 
would this defeat the point of advice/metaprogramming? This is similar 
to a recent thread asking how to support debug logs, where these two 
mechanisms are common approaches to achieving it.

- Leo


> Message: 4
> Date: Wed, 7 Apr 2010 02:08:40 -0700
> From: John Carlson <john.carlson3 at sbcglobal.net>
> Subject: Re: [cap-talk] Can Capabilities be configured?
> To: "General discussions concerning capability systems."
> 	<cap-talk at mail.eros-os.org>
> Message-ID: <09838C4C-F3E3-45A0-8A27-122505ADFE47 at sbcglobal.net>
> Content-Type: text/plain; charset="us-ascii"
>
> You might be able to configure capabilities with aspects, but aspects tend to violate capabilities.
>
> Look for attenuating capabilities--removing permissions in a deep tree-like structure (like a file system).
>
> John
> On Mar 17, 2010, at 11:24 AM, Yuvaraj Athur Raghuvir wrote:
>
>   
>> Hello,
>>
>> I have just started looking into Capability based Objects and learning E. I am impressed by how the simple and powerful the Granovetter Diagram is. The E language design is interesting and I am enjoying the way the language has been designed.
>>
>> After understanding the difference between the Capabilities and Access Control Lists (ACLs), one question that came up in my mind was how to 'externally configure' capabilities.
>>
>> In a way this an oxymoron as capabilities are designed to be granted to enable use. However, in real life situations of software use, it seems that all possibilities of flow of capabilities might not be possible to define up front and so embed that flow in code. It seems to me that ACLs are successful because of the late configuration possibility - the custodians of a resource can decide who has access and this is recorded in a look-up table. 
>>
>> Now, 
>> 1) Can capabilities be late configured? 
>> 2)Will that violate the fundamental principles of how capabilities are designed?
>> 3) If late configuration is possible, is there a pattern that shows how this can be done?
>>
>> Regards,
>> Yuva
>>
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>