On Feb 19, 7:45 am, Attila Szegedi <[email protected]> wrote:
> If this is the security exception you're getting, then I'd wager  
> there's a bug somewhere in the weblogic.utils.classloaders.* code.  
> Either that, or it is not a bug, but they don't anticipate code source  
> URLs from outside the app directory... what happens if your script's  
> code source URL points to somewhere within the webapp directory?
>
> Now, the java.security.debug="access,failure" will print stack traces  
> for all failures *even* if they are caught and later handled by the  
> code. Without java.security.debug in effect, what is the stack trace  
> of the SecurityException that is preventing normal execution? I'm  
> assuming it's different from (java.io.FilePermission D:\Demo\Demo\APP-
> INF\classes\org\mozilla\javascript\NativeJavaTopPackage.class read)...
>
> If it is the same exception, then I think we have a case of overeager  
> security lockdown in Weblogic, which you might get around if you use a  
> code source URL that points within some location Weblogic expects. A  
> long-term solution would be for us to use a doPrivileged() block when  
> LazilyLoadedCtor is used to load a class from org.mozilla.javascript.*  
> package.
>
> Attila.
>
> On 2009.02.18., at 21:13, [email protected] wrote:
>
>
>
> > On Feb 18, 6:40 am, Attila Szegedi <[email protected]> wrote:
> >> Probably the app server places additional restrictions on code in
> >> applications. It might be possible that you'd need to grant some
> >> additional privileges to js.jar when it's in app directory (and then
> >> we might need to augment Rhino to use doPrivileged() in few places
> >> after you identify those places).
>
> >> I suggest you run your JVM with -
> >> Djava.security.debug="access,failure"
> >> and see exactly what code fails obtaining which permissions, and come
> >> back to us with the findings.
>
> >> Attila.
>
> >> On 2009.02.17., at 23:31, Gary Brown wrote:
>
> >>> I have some code similar to the following that is used to call js  
> >>> code
> >>> from java.
>
> >>>    ContextFactory contextFactory = new ContextFactory();
> >>>    Context context = contextFactory.enterContext();
> >>>    context.setSecurityController( new PolicySecurityController() );
> >>>    Scriptable scope = context.initStandardObjects( new
> >>> ImporterTopLevel( context ) );
> >>>    URL url = new URL( "http://acme.com/scripting/test.js"; );
> >>>    CodeSource codeSource = new CodeSource( url, ( CodeSigner[] )
> >>> null );
> >>>    context.evaluateString( scope, script, "test.js", 0,  
> >>> codeSource );
> >>>    Context.exit();
>
> >>> The code works and can be secured using java policy when executed  
> >>> from
> >>> a simple stand-alone application. The code also works correctly when
> >>> executed from a web application running on Weblogic 10.0, but only  
> >>> if
> >>> js.jar from Rhino 1.7R1 is in the classpath. The file js.jar must be
> >>> placed ahead of the Weblogic jars in the classpath because one of  
> >>> the
> >>> classes conflicts with a class found in the Weblogic jars.
>
> >>> The following is an example of the java policy file:
>
> >>>    // Give java code full access.
> >>>    grant codeBase "file:/-" {
> >>>        permission java.security.AllPermission;
> >>>    };
>
> >>>    grant codeBase "file:C:/-" {
> >>>        permission java.security.AllPermission;
> >>>    };
>
> >>>    grant codeBase "file:D:/-" {
> >>>        permission java.security.AllPermission;
> >>>    };
>
> >>>    // Give javascript code no access.
> >>>    grant codeBase "http://acme.com/scripting"; {
> >>>    };
>
> >>> If I remove js.jar from the classpath and instead put js.jar in the
> >>> APP-INF/lib directory (I also have to put a weblogic-application.xml
> >>> file in the META-INF directory to fix the class load conflict), I  
> >>> get
> >>> security exceptions. The security exceptions go away if I grant full
> >>> permissions to all code.
>
> >>> -----
> >>> I get similar results when I deploy my code to Tomcat 6. If js.jar  
> >>> is
> >>> placed in $CATALINA_HOME/lib/ (and not in /WEB-INF/lib/), all is  
> >>> well.
> >>> If js.jar is placed in /WEB-INF/lib/, I get 'ReferenceError:  
> >>> "java" is
> >>> not defined.' unless I grant full permissions to all code.
> >>> -----
>
> >>> Is there any way to get this code to execute correctly without  
> >>> putting
> >>> js.jar in the common classpath? Any idea why the code works with
> >>> reduced permissions with js.jar in the common classpath, and with  
> >>> full
> >>> permissions with js.jar in the application classpath, but not with
> >>> reduced permissions with js.jar in the application classpath?-  
> >>> Hide quoted text -
>
> >> - Show quoted text -
>
> > This is a summary of the failures:
>
> > access: access denied (java.io.FilePermission D:\Demo\Demo\APP-INF
> > \classes\org\mozilla\javascript\NativeJavaTopPackage.class read)
> > access: domain that failed ProtectionDomain  (http://acme.com/
> > scripting <no signer certificates>)
> > access: access denied (java.io.FilePermission D:\Demo\Demo\APP-INF
> > \classes\org\mozilla\javascript\resources\Messages.class read)
> > access: domain that failed ProtectionDomain  (http://acme.com/
> > scripting <no signer certificates>)
> > access: access denied (java.io.FilePermission D:\Demo\Demo\APP-INF
> > \classes\org\mozilla\javascript\resources\Messages_en.class read)
> > access: domain that failed ProtectionDomain  (http://acme.com/
> > scripting <no signer certificates>)
> > access: access denied (java.io.FilePermission D:\Demo\Demo\APP-INF
> > \classes\org\mozilla\javascript\resources\Messages_en_US.class read)
> > access: domain that failed ProtectionDomain  (http://acme.com/
> > scripting <no signer certificates>)
> > access: access denied (java.io.FilePermission D:\Demo\Demo\APP-INF
> > \classes\org\mozilla\javascript\EcmaError.class read)
> > access: domain that failed ProtectionDomain  (http://acme.com/
> > scripting <no signer certificates>)
> > java.security.AccessControlException: access denied
> > (java.io.FilePermission D:\Demo\Demo\APP-INF\classes\org\mozilla
> > \javascript\EcmaError.class read)
>
> > This is the detail of the first and last failures:
>
> > .
> > .
> > .
> > access: access allowed (java.net.SocketPermission acme.com resolve)
> > access: access denied (java.io.FilePermission D:\Demo\Demo\APP-INF
> > \classes\org\mozilla\javascript\NativeJavaTopPackage.class read)
> > java.lang.Exception: Stack trace
> >    at java.lang.Thread.dumpStack(Thread.java:1158)
> >    at java.security.AccessControlContext.checkPermission
> > (AccessControlContext.java:253)
> >    at java.security.AccessController.checkPermission
> > (AccessController.java:427)
> >    at java.lang.SecurityManager.checkPermission(SecurityManager.java:
> > 532)
> >    at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
> >    at java.io.File.exists(File.java:700)
> >    at weblogic.utils.classloaders.DirectoryClassFinder.getSource
> > (DirectoryClassFinder.java:36)
> >    at weblogic.utils.classloaders.JarClassFinder.getSource
> > (JarClassFinder.java:45)
> >    at weblogic.utils.classloaders.AbstractClassFinder.getClassSource
> > (AbstractClassFinder.java:17)
> >    at weblogic.utils.classloaders.MultiClassFinder.getClassSource
> > (MultiClassFinder.java:58)
> >    at weblogic.utils.classloaders.MultiClassFinder.getClassSource
> > (MultiClassFinder.java:58)
> >    at weblogic.utils.classloaders.MultiClassFinder.getClassSource
> > (MultiClassFinder.java:58)
> >    at weblogic.utils.classloaders.CodeGenClassFinder.getClassSource
> > (CodeGenClassFinder.java:27)
> >    at weblogic.utils.classloaders.GenericClassLoader.findLocalClass
> > (GenericClassLoader.java:280)
> >    at weblogic.utils.classloaders.GenericClassLoader.findClass
> > (GenericClassLoader.java:259)
> >    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> >    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> >    at weblogic.utils.classloaders.GenericClassLoader.loadClass
> > (GenericClassLoader.java:179)
> >    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> >    at java.lang.Class.forName0(Native Method)
> >    at java.lang.Class.forName(Class.java:164)
> >    at org.mozilla.javascript.Kit.classOrNull(Kit.java:74)
> >    at org.mozilla.javascript.LazilyLoadedCtor.buildValue
> > (LazilyLoadedCtor.java:107)
> >    at org.mozilla.javascript.LazilyLoadedCtor.init
> > (LazilyLoadedCtor.java:89)
> >    at org.mozilla.javascript.ScriptableObject.getImpl
> > (ScriptableObject.java:1992)
> >    at org.mozilla.javascript.ScriptableObject.get
> > (ScriptableObject.java:280)
> >    at org.mozilla.javascript.IdScriptableObject.get
> > (IdScriptableObject.java:385)
> >    at org.mozilla.javascript.ImporterTopLevel.get
> > (ImporterTopLevel.java:128)
> >    at org.mozilla.javascript.ScriptableObject.getProperty
> > (ScriptableObject.java:1575)
> >    at org.mozilla.javascript.ScriptRuntime.topScopeName
> > (ScriptRuntime.java:1748)
> >    at org.mozilla.javascript.ScriptRuntime.name(ScriptRuntime.java:
> > 1650)
> >    at org.mozilla.javascript.gen.c1._c0(C:\temp\demo.js:1)
> >    at org.mozilla.javascript.gen.c1.call(C:\temp\demo.js)
> >    at org.mozilla.javascript.ContextFactory.doTopCall
> > (ContextFactory.java:401)
> >    at org.mozilla.javascript.ScriptRuntime.doTopCall
> > (ScriptRuntime.java:3003)
> >    at org.mozilla.javascript.gen.c1.call(C:\temp\demo.js)
> >    at org.mozilla.javascript.gen.c1.exec(C:\temp\demo.js)
> >    at org.mozilla.javascript.Context.evaluateString(Context.java:
> > 1088)
> >    at com.acme.script.ScriptHelper.call(ScriptHelper.java:514)
> >    at com.acme.script.ScriptHelper.call(ScriptHelper.java:407)
> >    at com.acme.demo.NumberNegativeEvent.service
> > (NumberNegativeEvent.java:91)
> >    at com.acme.next.next.NextController.processCurrentEvent
> > (NextController.java:622)
> >    at com.acme.next.next.NextController.processAllEvents
> > (NextController.java:359)
> >    at com.acme.next.next.NextController.service(NextController.java:
> > 181)
> >    at com.acme.next.Transaction.run(Transaction.java:136)
> >    at com.acme.next.TransactionObject.processTransaction
> > (TransactionObject.java:94)
> >    at com.acme.next.Loader.processRequest(Loader.java:1052)
> >    at com.acme.next.Loader.doService(Loader.java:727)
> >    at com.acme.next.Loader.service(Loader.java:548)
>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

If my script's code source URL points to somewhere within the webapp
directory then it works fine, but that is because my policy file
grants all code on the D: drive (the drive the webapp directory is on)
AllPermission.  My intent is to give the code in the webapp directory
all permissions, but to give the scripts no, or very limited
permissions.

If my script's code source URL points to the actual location of the
script file, "file:C:/temp/demo.js", and I use this policy file:

    grant codeBase "file:D:/-" {
        permission java.security.AllPermission;
    };
    grant codeBase "file:C:/temp/demo.js" {
    };

I get the same failure.


The exception that is preventing normal execution is:
java.security.AccessControlException: access denied
(java.io.FilePermission D:\Demo\Demo\APP-INF\classes\org\mozilla
\javascript\EcmaError.class read).  The detail of this exception can
be found at the end of my long post on Feb.  18, 2:13 pm.

However, I think that the first permission problem
(java.io.FilePermission D:\Demo\Demo\APP-INF\classes\org\mozilla\
javascript\NativeJavaTopPackage.class read) is the one that leads to
the exception that is not handled by the Rhino code.

This is the sequence as I see it.  The ScriptRuntime.name(Context,
Scriptable, String) method is trying to handle the first line of the
script, "importPackage(java.lang);".  It gets a file permission
problem attempting to read NativeJavaTopPackage.class.  It then tries
to throw notFoundError(scope, name), runs into three more permission
problems attempting to read Messages.class, Messages_en.class, and
Messages_en_US.class.  Finally, the constructError(...) method tries
to create an instance of EcmaError, cannot because of a file
permission problem attempting to read EcmaError.class, and a
java.security.AccessControlException is thrown.

This is not unique to Weblogic 10.0.  I get the same issue when I try
to run the same application on Tomcat 6.

I do have a workaround.  Granting the script's code source these
permissions fixes the problem on Weblogic 10.0 and Tomcat 6.

permission java.io.FilePermission "D:${/}Demo${/}Demo${/}APP-INF${/}
classes${/}-", "read";
permission java.io.FilePermission "D:${/}bea${/}user_projects${/}
domains${/}Demo${/}servers${/}AdminServer${/}tmp${/}_WL_user${/}Demo$
{/}xa8amf${/}APP-INF${/}lib${/}js.jar", "read";

On Tomcat 6, I also have to grant this runtime permission to eliminate
all failures listed in an "access,failure" trace.  The script works
without it however.

permission java.lang.RuntimePermission "accessDeclaredMembers";

Thank you very much for the help!
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Reply via email to