RE: [Jython-users] Jython interpreter access from EJB (access den ied)

[Thomas B. B. <tb...@sy...>]

Hi.

Thanks for a quick response. I was asked for a complete stack trace for the
"access denied" exception, which is here:

java.security.AccessControlException: access denied
(java.util.PropertyPermission * read,write)
        at
java.security.AccessControlContext.checkPermission(AccessControlContext.java
:272)
        at
java.security.AccessController.checkPermission(AccessController.java:399)
        at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
        at
java.lang.SecurityManager.checkPropertiesAccess(SecurityManager.java:1246)
        at java.lang.System.getProperties(System.java:488)
        at org.python.core.PySystemState.initialize(PySystemState.java:287)
        at
org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:61)
        at
org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:45)
        at jythonejb.JythonScriptBean.run(JythonScriptBean.java:25)
        at
jythonejb.JythonScriptBean_EJBObjectImpl.run(JythonScriptBean_EJBObjectImpl.
java:18)
        at jythonejb._JythonScriptBean_EJBObjectImpl_Tie._invoke(Unknown
Source)
        at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatchToServant(GenericPO
AServerSC.java:423)
        at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.internalDispatch(GenericPOA
ServerSC.java:137)
        at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatch(GenericPOAServerSC
.java:98)
        at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:227)
        at
com.sun.corba.ee.internal.iiop.CachedWorkerThread.doWork(IIOPConnection.java
:262)
        at
com.sun.corba.ee.internal.iiop.CachedWorkerThread.run(IIOPConnection.java:23
0)

I've tried to run the J2EE application server without a security policy
(tried to remove the 
"-Djava.security.policy==%J2EE_HOME%\lib\security\server.policy" from the
J2EE app.serv. startup), but with no luck so far. I've also tried to grant
(all) permissions to the (server) directory holding the jython.jar (2.0)
file. 

Best regards, Thomas





>Hi jython-users.
>
>I'm trying to implement a jython-based scripting service in the middle tier
>of a J2EE application. I have a basic "test" setup consisting of:
>
>1) A stateful EJB session bean deployed in the "standard" J2EE application
>server,
>2) A test client J2EE application, accessing that session bean, calling for
>a simple script execution.
>
>Setup 1) includes the jython.jar file, so the server should have access to
>the jython class files. Also, my small test client app get as far as
>obtaining the EJB object reference, but when it attempts to instantiate a
>new jython interpreter, like this:
>
>	JythonInterpreter interp = new JythonInterpreter();
>
>it catches the following exception:
>
>java.rmi.ServerException: RemoteException occurred in server thread; nested
>exception is:
>	java.rmi.RemoteException: Unknown Exception/Error thrown by EJB
>method.; nested exception is:
>		java.security.AccessControlException: access denied
>(java.util.PropertyPermission * read,write)

Try catching the exception and printing the stacktrace to stdout or to a
file.

    PythonInterpreter interp = null;
    try {
	interp = new PythonInterpreter();
    } catch (Exception exc) {
        exc.printStackTrace();
        throw exc;
    }

That may supply us with more information about the actual access
problem.

>--- I.e. I'm not even getting to execute an actual script.
>
>Clearly, with a jython scripting engine server-side one could imagine all
>kinds of not-so-funny things possible (which is why - I guess - I get the
>security exception), but in my case all I really need to do have is
>read-only access to the EJB's comprising my application (for validation
>purposes).
>
>Now, I have two questions:
>
>- What is it more specifically that makes an instantiation of a new jython
>interpreter cause a security exception?

The stacktrace will tell us, but the jython runtime does access several
system properties, read files and directories along the classpath and
attempt to load unsigned bytecode. All this and more require specific
access grants when running under a security manager.

The security manager is typically controlled by a file called something
with "policy". For instance in the jBoss EJB server it is called
conf\server.policy.

>- Is it at all reasonable (possible) to build a jython scripting service in
>the middle-tier, as sketched above?

Yes.

regards,
finn