AccessControlException with JMS, WebStart, and WebLogic
JayDS
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.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:824)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.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
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
JayDS
exception in the debugger, the detail message is just the
"access denied" and the cause is just itself again; there's
nothing about anything else in there that I can see.
If it matters, this works just fine outside of WebStart.
If you've got any other thoughts, let me know. Thanks!
rkm <r...@invalid.com> wrote in message news:<3F3D4DD3...@invalid.com>...
Roedy Green
quoted :
>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.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
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
quoted :
>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
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