Closed Bug 468385 Opened 12 years ago Closed 6 years ago

ScriptRuntime.initStandardObjects should be factored into sections, particularly lazilyNames

Categories

(Rhino Graveyard :: Core, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bugs, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: 1.7R1

Attempting to use Rhino to evaluate JavaScript expressions.  These expressions are not necessarily trusted, and have no reason to directly callback to Java, unless specific functionality is explicitly exported into the JavaScript context.

Calling Context.setClassShutter(...) is a start; however, the "lazilyNames" used by ScriptRuntime.initStandardObjects (called by Context.initStandardObjects(...)) still inserts references to org.mozilla.javascript.NativeJavaTopPackage ("Packages", "java", "javax", "org", "com", "edu", "net", "getClass"), org.mozilla.javascript.JavaAdapter ("JavaAdapter"), and org.mozilla.javascript.ImporterTopLevel ("JavaImporter").  These are not necessary for this and other use-cases, and there should be a method to make these optional.

It is not currently possible (without mass copy & paste) to avoid these declarations without loosing all the other core functionality provided by the initStandardObjects method, particularly all the Native*.init(...) calls for NativeObject, NativeError, NativeGlobal, NativeArray, NativeString, etc.

Reproducible: Always




Other keywords: Sandbox
One idea would be to add a variant of initStandardObjects that takes a filter argument to let embedders decide which global objects to set, similar to java.io.File.list(FilenameFilter):

cx.initStandardObjects(new GlobalObjectFilter() {
    public boolean accept(String name, Object value) {
       return !(value instanceof NativeJavaTopPackage) && 
              !"getClass".equals(name);
    }
});
Since the primary issue appears to be the LiveConnect classes, what about splitting initStandardObjects into initSafeStandardObjects which does everything in initStandardObjects except initialize the LiveConnect stuff, and initStandardObjects which wraps around it and adds the LiveConnect stuff. Then secure environments can just use initSafeStandardObjects instead.
That (comment #3) would work for me!
Ok, this patch should implement initSafeStandardObjects.
It compiles fine, and packages are still available to the shell. I haven't done thorough testing, I don't know what I'd test for/with, but this should work theoretically.
Attachment #397491 - Flags: review+
This was fixed at https://github.com/mozilla/rhino/issues/170 .  (Thanks, Greg!)
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.