Closed Bug 568671 Opened 12 years ago Closed 12 years ago

Base class for proxy-based wrappers implementing full membranes


(Core :: JavaScript Engine, defect)

Other Branch
Not set





(Reporter: jorendorff, Assigned: gal)




(1 file)

The most important thing to read is
which is kind of a hopeful fiction, partly describing the current state of play and partly describing where I think we want to be.

Or just read this fragment of code (attached). Unfortunately it's pre-proxy and overengineered-- the Membrane class is unnecessary. Now that I know what I want, it needs to just be a single AbstractWrapper class with a few pure virtual methods called, say,

  checkAccess(obj, id)

But the guts of jsmembrane.cpp is worth looking at.
We'll need a JS_SetCurrentCompartment in the constructor of AutoEnterMembrane and another in the destructor. (The "current compartment" of a cx controls which compartment/heap new objects are created in; see [1].)

But Blake convinced me yesterday that we do not need all the stack frame munging for any wrapper type except SJOW. The reason SJOWs "sever the stack" is to foil a specific attack via arguments.callee.caller. The attack works if the less-privileged code appears on the stack above (more recent than) more-privileged code. The only way this can happen is via a SJOW call. XPCNW wrapped functions are never plain JS functions; they always wrap XPCOM methods. It can't happen due to a wrappedjs because only chrome JS can implement COM interfaces.

[1] - Scroll down to the Compartments API.
Assignee: general → gal
Incomplete thoughts follow.

Another reason not to add a stack frame every time we cross the boundary... maybe... is that some XPCOM getters/setters/methods are designed to be called by callers of all different privilege levels. These are called allAccess properties--holdover stuff from before we had wrappers. The getter/setter itself examines the stack if it needs to know the caller's principals. So if the wrapper pushed a stack frame, that could be Bad. (I think this might be fixable but can't really say.)

This is a reminder that we're still transitioning from stack examination to object-capabilities, not there yet.
Blocks: 565735
We implemented this elsewhere. Closing.
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.