On Apr 23, 2013, at 3:31 AM, Mark S. Miller wrote:
> On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock <[email protected]>
> wrote:
> We don't currently have the concept of an object "belonging" to a realm.
> Functions have a realm association, but not non-function object.
>
> The current idea on how to solve the security issue with weak references (and
> AFAIK the only solution that has been suggested) assumes that objects are
> identified with the realm of their creation, so that we can distinguish
> intra-realm vs inter-realm pointing. I will let others speak of the
> implementation cost. Here, I'll see if we can define a simple semantics for
> an object's realm of origin.
>
> * We agree that functions are identified with a realm. An object literal
> within a function should evaluate to an object in the same realm as that
> function.
>
> * Various built-in functions, notably Object.create but also, e.g.
> Array.prototype.map, create objects. For each such "Chapter 15" builtin
> function, again the object should be created in the realm of the function
> that creates it.
>
> What other cases are there? (I thought it would be a longer list ;).)
There a many syntactic constructs that allocated objects (class definitions,
template strings, comprehensions, anything that does a ToObject, etc. Also,
many ES6 chapter 15 functions (including all the @@create methods) allocate
objects. In both cases, the actual allocations are usually indirected through
abstraction operations.
All ECMAScript functions and all chapter 15 built-ins belong to a realm and
when such functions are called its realm is recorded as part of a new execution
context (in ES6, calling a built-ins is specified to create a new execution
contexts). By the time the ES6 spec. is completed, I'm sure that ECMAScript
scripts will also belong to realms and have execution contexts. Calling
abstract operation don't create execution contexts. So, every specified way to
create an object occurs within the scope of an execution context that is
associated with a specific realm. (however, host or implementation provided
exotic function objects that don't use the ordinary [[Call]] are unspecified
and might be implemented to do something that doesn't including creating a new
execution context).
So I'm not particular concerned about the specification complexity of
associating every object with a realm. However, I do think that potential
implementation impacts should be studied very carefully.
Even if we had per object realm associations, it isn't clear to me what exactly
we are trying to block WRT cross-realm [[Prototype]] chains. Is the assertion
that all objects in a [[Prototype]] chain must come from the same realm. Does
that mean that we must block creating such chains via Object.create or class
declarations or classic constructor functions. It isn't clear to me why such
cross-realm chains are necessarily evil. It also isn't clear to me why
__proto__ should be prevented from creating them if we don't also prevent all
other ways of doing so. In that case, the appropiate place to put semantic
restrictions on prototype chain construction/modification is in the semantics
of the ordinary object [[SetInheritance]] internal method rather than in
individual built-in functions and abstract operations that invoke
[[SetInheritance]].
Allen
>
>
>
>
> Object.create(parent); //we have no way to determine if parent "belongs"
> to the same realm as Object.create.
> we also currently have no way to determine whether the caller of
> Object.create is in the same or different realm as Object.create.
>
> someObject.__proto__ = someParent; //the setter function from
> Object.prototype has no way to determine a realm association for someParent.
>
> let protoSetter = Object.getOwnPropertyDescriptor(Object.prototype,
> "__proto__"); //a proto setter from some realm
>
> let x = {};
> protosetter.call(x, another); //no realm info to validate.
>
> protosetter is essentially a universal setPrototypeOf function.
>
> The only way I see to tame any aspect (for example not allowing
> Object.prototype.__proto__ = something) of __proto__ setting is via a [[Set]]
> over-ride on Object.prototype.
>
> Allen
>
>
>
> On Apr 22, 2013, at 7:29 AM, Andreas Rossberg wrote:
>
> > On 22 April 2013 15:49, Brendan Eich <[email protected]> wrote:
> >>> However, in that case, I actually think that there is no need to have
> >>> any special poisoning semantics when reflecting __proto__ -- mainly
> >>> because the cross-realm check is already necessary in the unreflected
> >>> case: you can construct an object o in realm A with an
> >>> Object.prototype from another realm B on its proto chain. If you
> >>> deleted __proto__ on realm's A Object.prototype, I don't think it
> >>> should still be possible to assign to o.__proto__, should it?
> >>
> >> Why not, if in realm A we evaluate 'var o =
> >> Object.create(B.Object.prototype)'? You specified 'delete
> >> A.Object.prototype' happened, and A.Object.prototype is not on o's proto
> >> chain.
> >
> > My understanding of the motivation for poisoning was to enable the
> > deletion of O.p.__proto__ when configuring a realm as a means for
> > guaranteeing that no object from that realm can ever have its
> > prototype mutated. Allowing the above case would seem to shoot a hole
> > into that.
> >
> > // Realm A
> > delete Object.prototype.__proto__ // no messing around
> >
> > let other = getObjectFromSomewherePotentiallyAnotherRealmB()
> >
> > let p1 = Object.create(other, {a: {value: 1}})
> > let o = Object.create(p1)
> > let p2 = Object.create({})
> > o.__proto__ = p2 // say what?
> >
> >
> >>> Whether a
> >>> difference should be made between quoted and unquoted I don't know, I
> >>> must have missed the rationale for such a move.
> >>
> >> I think we're not going to induce vomiting by making a quoted vs. unquoted
> >> distinction, in light of Mark's point about computed property names.
> >
> > OK, good. :)
> >
> > /Andreas
> > _______________________________________________
> > es-discuss mailing list
> > [email protected]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
>
> --
> Cheers,
> --MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
