Java Web Start安全警告，尽管使用了所有权限和特权操作

我已经在JBoss（4.2.2.GA）服务器和J2SE客户端之间建立了JMS连接。客户机通过Java Web Start运行，在JNLP中，我有以下内容：

<jnlp version="1.5+" codebase="$$codebase" href="start.jnlp">
    <!-- Information -->
    <security>
        <all-permissions />
    </security>
    <resources>
        <!-- Some other non-JMS resources -->
        <jar href="concurrent.jar" />
        <jar href="jboss-common.jar" />
        <jar href="jboss-j2ee.jar" />
        <jar href="jbossmq.jar" />
        <jar href="jnpserver.jar" />
        <jar href="log4j.jar" />
    <resources>
</jnlp>

此外，JAR都是使用我们的公司证书签署的，该证书是通过CA颁发的（将在未来几个月内到期，但仍然有效）。我还尝试清除

javaws

缓存，以确保它不是过时的代码问题

那么为什么警告还在继续呢？我将它作为一个特权操作运行，据我所知，它应该只从JNLP文件中授予代码

所有权限

策略，但是当

sun.rmi.transport.tcp.tcpcchannel.checkConnectPermission（）

在JNDI查找期间被调用时，JWS安全管理器会发出安全警告。为了使JNDI查找具有提升的连接权限，我还必须配置其他东西吗？我可以通过JavaWebStart配置吗

更新

我还在处理这个问题。我缩小了对话框的范围，使其在尝试访问服务器上的RMI端口时出现（它正在检查权限

host:1098

）。我尝试将

java.rmi.server.hostname

属性设置为

host

，从而取消了中列出的解决方法。由于第一次RMI查找直到客户机启动之后才发生，因此我假设不需要通过

找到将其添加到JNLP文件的方法

以下是我在安全警告中单击“取消”时的堆栈跟踪：

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)
    ...

---

因此，问题是特定于RMI访问的。为什么设置主机名不能修复对话框，正如链接的bug报告中的解决方法和我找到的一些其他资源中所建议的那样？还有其他解决方法吗？

解决方案是一个大难题，但我只能找到它

除了信息之外，JWS安全管理器没有将RMI代码列为可信代码，因为它是在单独的类加载器下加载的。因为代码不是来自JNLP，所以JWS不允许它使用

all permissions

security运行

针对这一问题的黑客修复方法只是简单地用以下内容包装每个查找：

Topic topic = null;
SecurityManager prevSecurityManager = System.getSecurityManager();
try {
    System.setSecurityManager(null);
    topic = (Topic) context.lookup(name);
} finally {
    System.setSecurityManager(prevSecurityManager);
}

将

SecurityManager

设置为

null

会绕过JWS安全管理器，让默认的安全管理器接管

---

最后，我想找到一种方法，将RMI代码添加到JNLP的可信代码库中，但是在我能够做到这一点之前，这个解决方案将在我们的开发环境和演示中工作。这不是一种非常安全的方法，尤其是在这样的多线程应用程序中。在没有安全管理器的情况下，它提供了一个很小的机会窗口，因此，如果任何人有一个解决方案可以让我信任JNLP配置中的RMI代码，发布它，您的答案将被接受（当然前提是它工作正常）。

可能相关：我们的目标环境是Java 6u17，我无法更改它。

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)
    ...

Topic topic = null;
SecurityManager prevSecurityManager = System.getSecurityManager();
try {
    System.setSecurityManager(null);
    topic = (Topic) context.lookup(name);
} finally {
    System.setSecurityManager(prevSecurityManager);
}