AccessControlException with JMS, WebStart, and WebLogic

[JayDS]

I am attempting a simple JMS program under WebStart, and am having
security
issues occur which I don't understand. My jar files are signed and I
have
<all-permissions/> in my JNLP file. Yet when I try to lookup the
TopicConnectionFactory, I get an AccessControlException.

I am apparently missing something, but I'm not sure what. My best
guess is
something related to the class loader, but I've got no clue as to how
to
proceed. If anyone has encountered something like this before, please
shed
some light in this darkness. Thanks!

Here is the code I am executing

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://hostname:7001");
System.out.println( "Creating context..." );
InitialContext ctx = new InitialContext(env);
System.out.println( "Looking up factory..." );
connectionFactory = (TopicConnectionFactory)
ctx.lookup("jms/nib/connectionFactory");
System.out.println( "Creating topic connection..." );
connection = (TopicConnection)
connectionFactory.createTopicConnection();
System.out.println( "Creating topic session..." );

and here is the exception that gets generated:

Creating context...
Looking up factory...
java.security.AccessControlException: access denied
(java.lang.RuntimePermission getClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.ClassLoader.getParent(ClassLoader.java:701)
at weblogic.rmi.internal.ClientRuntimeDescriptor.computeInterfaces(ClientRuntimeDescriptor.java:253)
at weblogic.rmi.internal.ClientRuntimeDescriptor.intern(ClientRuntimeDescriptor.java:123)
at weblogic.rmi.internal.StubInfo.readObject(StubInfo.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.ibjectStreamClass.invokeReadObject(ObjectStreamClass.java:824)
at java.ibjectInputStream.readSerialData(ObjectInputStream.java:1746)
at java.ibjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.ibjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.ibjectInputStream.readObject(ObjectInputStream.java:324)
at weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:140)
at weblogic.jms.client.JMSConnectionFactory.readExternal(JMSConnectionFactory.java:173)
at weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:131)
at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:91)
at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:56)
at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:161)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:263)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:229)
at weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(Unknown
Source)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:337)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:332)
at javax.naming.InitialContext.lookup(InitialContext.java:347)

and just in case it helps, here's the JNLP file

<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for WatermarkDemo -->
<jnlp
spec="1.0+"
codebase="$$codebase"
href="$$name">

<information>
<title>JMSTest</title>
<vendor>Testing</vendor>
<description>Just a JMST test</description>
</information>

<security><all-permissions/></security>

<resources>
<j2se version="1.4+"/>
<jar href="jmstest.jar" main="true"/>
<jar href="weblogic.jar"/>
</resources>

<application-desc main-class="JMSTest"/>

</jnlp>

: jay

 

[rkm]

I had this exact same symptom while developing some RMI
code, and it turned out to have nothing to do with security,
even though I was getting the AccessControlException. The
way I figured it out was by trapping the exception in the
debugger, then examining the exceptions internal message,
which had a cause related to deserialization. This made me
suspect my http server was not downloading the correct code,
and restarting it and rmid at the same time solved the
problem. I have also got the same exception when trying to
register a duplicate RMI service name. Seems like whatever
errors get generated on the server side are trapped on the
client side and rethrown as a security exception.
HTH,
Rick

 

[Roedy Green]

If it matters, this works just fine outside of WebStart.

In the JNLP file you request some privileges. Perhaps you asked for
more than you needed.

 

[JayDS]

In the JNLP file you request some privileges. Perhaps you asked for
more than you needed.

Well, I really do need <all-permissions/> in the real app upon which
this simple test program is based. However, for this app, I did try
using <j2ee-application-client-permissions/> just to see what would
happen, and this gives me a similar access exception, though a bit
earlier; see stack trace below. With this permission, I get the error
trying to create the initial context rather than on the lookup.

Any other thoughts?

: jay

---- stack trace ---

Starting...
Creating context...
java.lang.ExceptionInInitializerError
at weblogic.jndi.WLInitialContextFactoryDelegate.<clinit>(WLInitialContextFactoryDelegate.java:164)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:140)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:145)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.<init>(InitialContext.java:195)
at JMSTest.<init>(JMSTest.java:25)
at JMSTest.main(JMSTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission getClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1031)
at weblogic.utils.classloaders.GenericClassLoader.getAugmentableSystemClassLoader(GenericClassLoader.java:633)
at weblogic.rmi.internal.ClientRuntimeDescriptor.<clinit>(ClientRuntimeDescriptor.java:49)
... 21 more

 

[Roedy Green]

Well, I really do need <all-permissions/>

Let's look at it from the other end. See
http://mindprod.com/policyfile.html to figure out which policyfile is
the policyfile in effect. Show us what those say. Perhaps those are
set to reject you.

 

[JayDS]

Finally used the right keywords to get a good hit in the bug database:

http://developer.java.sun.com/developer/bugParade/bugs/4809366.html

Turns out this is an issue with WebLogic, and BEA's recommended work
around is to modify the local policy file.

: jay