Re: eval.hermetic(program :(string | AST), thisValue, optBindings) :any Is a 'canonical' AST part of the plans for ecmascript 6/harmony.
On Wed, May 6, 2009 at 8:59 PM, Mark S. Miller <[email protected]> wrote: > On Wed, May 6, 2009 at 10:53 AM, Mark S. Miller <[email protected]> wrote: >> [...] For the Valija-like level, I >> think the most important enabler would be some kind of hermetic eval >> or spawn primitive for making a new global context (global object and >> set of primordials) whose connection to the world outside itself is >> under control of its spawner. With such a primitive, we would no >> longer need to emulate inheritance and mutable globals per sandbox. > > May as well get us started with a strawman, intended only to provide > the global object separations, not any scheduling separations. Whether > these two issues should in fact be coupled or decoupled is an > interesting question. > > eval.hermetic(program :(string | AST), thisValue, optBindings) :any > eval.spawn(optBindings, optGlobalSubsetDirective :Opt(string)) :Sandbox > > interface Sandbox { > public getGlobal() :GlobalObject; > public deactivate(problem :string) :void; > } > > eval.hermetic() does an indirect eval of the program in the current > global context, but, as in > <http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope>, > without the global object at the bottom of the scope chain. > * Unlike <http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope>, > the 'this' value in scope at the top of the evaluated program is the > provided thisValue; so a caller without access to their own global > object cannot grant access they don't have. If the 'thisValue' is > absent, then the global 'this' of the evaled program is undefined. > * If optBindings is absent or falsy, then the bottom of the scope > chain is populated with the ES spec defined global bindings, i.e., > {Object: Object, Array: Array, etc...}. If optBindings is provided and > truthy, then its *own* properties (or perhaps its enumerable > properties, or its enumerable own properties?) are uses to populate > the bottom of the scope chain. In either case, the object at the > bottom of a hermetic scope chain is a declarative environment record, > not an object environment record. > > eval.spawn() makes a new global context -- a global object and a set > of primordials. This new global context is subsidiary to the present > one for (at least) deactivation and language subsetting purposes, so > spawning forms a tree. > * If optBindings are provided, its own properties are copied over to > populate the newly created global object. > * If optGlobalSubsetDirective is provided, then all code evaluated in > this global context is constrained as if by an outer lexical use > subset directive. Subset constraints compose across subsidiary spawns > -- as if the optGlobalSubsetDirective of outer sandboxes were yet more > outer lexical use subset directives. > * It returns a Sandbox object for interacting with that new global > context: obtaining its global object or deactivating all objects > created within this global context or any subsidiary global contexts. > If there are any live stack frames executing within a context that > would be deactivated at the time sandbox.deactivate() is called, then > deactivate throws and has no other effect. > > One then runs code hermetically within a sandbox by > > sandbox.getGlobal().eval.hermetic(...) > > Given good catchalls and weak-key-tables, good membranes should be > possible. Indeed, this should be a litmus test of catchall proposals. > Given good membranes, one can easily gain other desired security > properties by interposing membranes around some of the above objects. > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
