[cap-talk] Can Capabilities be configured?
lmeyerov at eecs.berkeley.edu
Wed Apr 7 09:31:02 PDT 2010
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
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):
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.
> 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).
> On Mar 17, 2010, at 11:24 AM, Yuvaraj Athur Raghuvir wrote:
>> 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.
>> 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?
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
More information about the cap-talk