Closed Bug 355590 Opened 14 years ago Closed 14 years ago

__parent__ should not expose lexical scope or activation objects

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8.1

People

(Reporter: brendan, Assigned: brendan)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

This is a standards violation and an optimization hazard.  Trivial patch next.

/be
Attached patch fixSplinter Review
Attachment #241369 - Flags: review?(igor.bukanov)
Attachment #241369 - Flags: review?(mrbkap)
Attachment #241369 - Flags: approval1.8.1?
Attachment #241369 - Flags: approval1.8.1.1?
Attachment #241369 - Flags: review?(igor.bukanov) → review+
Comment on attachment 241369 [details] [diff] [review]
fix

>+            /* Censor activations and lexical scopes per ECMA-262. */

But ECMA does not have __parent__! Or to be precise it never exposes the activation objects to scripts.
(In reply to comment #2)
> (From update of attachment 241369 [details] [diff] [review] [edit])
> >+            /* Censor activations and lexical scopes per ECMA-262. */
> 
> But ECMA does not have __parent__! Or to be precise it never exposes the
> activation objects to scripts. 

Yes, that's the point! ;-)

/be
Status: NEW → ASSIGNED
Attachment #241369 - Flags: review?(mrbkap) → review+
Would it be better for compatibility to search prototype chain for the real scope?
(In reply to comment #4)
> Would it be better for compatibility to search prototype chain for the real
> scope?

__parent__ was always just a reflection of JSSLOT_PARENT.  So compatibility is maintained by leaving the code alone, just censoring the lexical scope objects.  It turns out that __parent__ is handy for debugging (possibly for the testsuite too) as a way to get to the Call object, but we can provide an alternative method for the suite if we have to.  The other, valid uses of __parent__ (e.g. to get to the DOM scope chain link) continue to work.

We don't want to let would-be lexical scopes to leak via either __proto__ or __parent__, and so the patch does not depend on the id of the built-in property being accessed.

Fixed on trunk:

Checking in jsobj.c;
/cvsroot/mozilla/js/src/jsobj.c,v  <--  jsobj.c
new revision: 3.292; previous revision: 3.291
done

/be
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Comment on attachment 241369 [details] [diff] [review]
fix

Approved for RC3.
Attachment #241369 - Flags: approval1.8.1? → approval1.8.1+
Attachment #241369 - Flags: approval1.8.1.1?
Fixed on the 1.8 branch:

Checking in jsobj.c;
/cvsroot/mozilla/js/src/jsobj.c,v  <--  jsobj.c
new revision: 3.208.2.36; previous revision: 3.208.2.35
done

/be
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.