468385 - ScriptRuntime.initStandardObjects should be factored into sections, particularly lazilyNames

Status: RESOLVED INVALID

(Rhino Graveyard :: Core, defect)

Description

[Mark A. Ziesemer]

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

Comment 1

[Hannes Wallnoefer]

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);
    }
});

Comment 2

[Mark A. Ziesemer]

See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6782031

Comment 3

[Daniel Friesen]

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.

Comment 4

[Mark A. Ziesemer]

That (comment #3) would work for me!

Comment 5

[Daniel Friesen]

Attachment: Should implement initSafeStandardObjects

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.

Comment 6

[Mark A. Ziesemer]

This was fixed at https://github.com/mozilla/rhino/issues/170 .  (Thanks, Greg!)