title: Java Web Start security warning despite using all-permissions and privileged action
body: <p>I have set up JMS connections between my JBoss (4.2.2.GA) server and our J2SE client. The client runs via Java Web Start, and in the JNLP, I have the following:</p>
  
  <pre><code>&lt;jnlp version="1.5+" codebase="$$codebase" href="start.jnlp"&gt;
      &lt;!-- Information --&gt;
      &lt;security&gt;
          &lt;all-permissions /&gt;
      &lt;/security&gt;
      &lt;resources&gt;
          &lt;!-- Some other non-JMS resources --&gt;
          &lt;jar href="concurrent.jar" /&gt;
          &lt;jar href="jboss-common.jar" /&gt;
          &lt;jar href="jboss-j2ee.jar" /&gt;
          &lt;jar href="jbossmq.jar" /&gt;
          &lt;jar href="jnpserver.jar" /&gt;
          &lt;jar href="log4j.jar" /&gt;
      &lt;resources&gt;
  &lt;/jnlp&gt;
  </code></pre>
  
  <p>The JMS connection is working fine. I have successfully configured, subscribed to, and tested a JMS topic. Here is that code:</p>
  
  <pre><code>final String topic = ... ;
  final InitialContext context = new InitialContext();
  PrivilegedAction&lt;JmsConnectionContext&gt; action = new PrivilegedAction&lt;JmsConnectionContext&gt;() {
  
      @Override
      public JmsConnectionContext run() {
          try {
              TopicConnectionFactory connectionFactory = (TopicConnectionFactory) context.lookup("TopicConnectionFactory");
              TopicConnection topicConnection = connectionFactory.createTopicConnection();
              int sessionId = Client.getSession().getSessionId();
              topicConnection.setClientID("UMClient-" + sessionId);
              TopicSession session = topicConnection.createTopicSession(false,
                      TopicSession.AUTO_ACKNOWLEDGE);
  
              Topic jmsTopic = (Topic) context.lookup(topic);
              TopicSubscriber subscriber = session.createDurableSubscriber(jmsTopic, topic + "-" +
                      sessionId);
              subscriber.setMessageListener(new JmsTopicMessageListener());
              topicConnection.start();
              return new JmsConnectionContext(topic, topicConnection, session);
          } catch(Exception e) {
              logger.log(Level.SEVERE, "Topic creation and connection failed.", e);
              return null;
          }
      }
  };
  return AccessController.doPrivileged(action);
  </code></pre>
  
  <p>And my JNDI properties configuration is very straightforward:</p>
  
  <pre><code>java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
  java.naming.factory.url.pkgs=org.jboss.naming
  java.naming.provider.url=10.1.3.143:1099
  </code></pre>
  
  <p>Also, the jars have all been signed using our company certificate, which was issued via a CA (set to expire within the next few months, but it's still valid). I've also tried clearing the <code>javaws</code> cache to make sure it wasn't an outdated code issue.</p>
  
  <p>So why is the warning still coming up? I'm running it as a privileged action which, as far as I understand, should just grant the code the <code>all-permissions</code> policy from the JNLP file, but yet when <code>sun.rmi.transport.tcp.TCPChannel.checkConnectPermission()</code> gets called during the JNDI lookup, the JWS security manager brings up the security warning. Is there something else I have to configure for the JNDI lookups to have elevated connection privileges, and can I configure that over Java Web Start?</p>
  
  <p><strong>Update</strong></p>
  
  <p>I'm still dealing with this problem. I narrowed down the dialog to coming up when it tries to access the RMI port on the server (it's checking permission<code>host:1098</code>). I tried setting the <code>java.rmi.server.hostname</code> property to <code>host</code>, going off of the workaround listed in <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6533026" rel="nofollow">this bug report</a>. Since the first RMI lookup doesn't happen until after the client is already started, I assume that I don't need to find a way to add it to the JNLP file via a <code>&lt;property&gt;</code>.</p>
  
  <p>Here's the stack trace from when I click "cancel" in the security warning:</p>
  
  <pre><code>java.security.AccessControlException: access denied (java.net.SocketPermission 10.1.3.143:1098 connect,resolve)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkConnect(Unknown Source)
      at com.sun.javaws.security.JavaWebStartSecurity.checkConnect(Unknown Source)
      at sun.rmi.transport.tcp.TCPChannel.checkConnectPermission(Unknown Source)
      at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
      at sun.rmi.server.UnicastRef.invoke(Unknown Source)
      at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
      at javax.naming.InitialContext.lookup(Unknown Source)
      at org.jboss.naming.LinkRefPairObjectFactory.getObjectInstance(LinkRefPairObjectFactory.java:85)
      at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source)
      at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1273)
      at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1290)
      at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1298)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:763)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
      at javax.naming.InitialContext.lookup(Unknown Source)
      at com.ultramain.uui.jms.JmsHelper.jndiLookup(JmsHelper.java:145)
      ...
  </code></pre>
  
  <p>So the problem is specific to RMI access. Why doesn't setting the hostname work to fix the dialog, as suggested in the workaround in the linked bug report and a few other resources I have found? Is there any other workaround to fix this?</p>