JDK-6533026 : An RMI connection to the remote host under Web Start produces a warning
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86
  • Submitted: 2007-03-09
  • Updated: 2013-04-12
Related Reports
Relates :  
JDK-4876235 - SocketService - Allow user to grant app "connect" permission to hosts other than the download host.
Description
FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Linux dev 2.6.13-15.13-smp #1 SMP Tue Nov 28 13:43:50 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
I tested this under Windows and Linux and got the same warning.

A DESCRIPTION OF THE PROBLEM :
I have a java web start app that access a server app using RMI.
I don't don't sign my jar, because I stay in the sandbox (My RMI server app in on the same machine as the jnlp file).
Under jdk 1.5 everything was okay.
Under jdk 1.6 (for any platform) I get a warning that 'The application has requested permission to establish connections to localcomputer. Do you want to allow this action?' (where localcomputer is the host name of the client computer)
It doesn't matter whether I click 'OK' or 'Cancel' on this dialog box, my app continues running fine.
The problem is, most of my users will freak out when they see this box.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Since reproducing this takes a bunch of files, I just stuck it on my server so you can take a quick look.
Run app from this URL using jdk 1.5 and then jdk 1.6.
Ignore the error you get after the warning dialog (I don't have the RMI server running).
http://www.donandann.com/hellormi/
Notice the warning under jdk 1.6.
If you want to reproduce this, you can get this entire (small) project, including the jnlp file, here:
http://www.donandann.com/hellormi/docs/HelloRMI.jar


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I don't expect rmi to try to access my client computer's local resources.
ACTUAL -
I get a warning under jdk 1.6 that 'The application has requested permission to establish connections to localcomputer. Do you want to allow this action?'

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No errors

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
http://www.donandann.com/hellormi/docs/HelloRMI.jar

Sorry, but there are a few small source files and a jnlp file required to get this to fail.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
If I dismiss the dialog, everything is okay.
Comments
EVALUATION The reported dialog that appears with the test case using JDK 6 but not JDK 5.0 is the result of a new feature of Java Web Start in JDK 6: see RFE 4876235. The purpose of the feature, as I understand it, is to allow the running of unsigned applications that require general network connectivity by synchronously interacting with the user before rejecting such an application's attempt to make or receive network connections, giving the user a change to let the attempt succeed instead of being rejected. More specifically, the mechanism is to use a security manager that overrides SecurityManager.checkConnect and checkAccept to invoke the corresponding superclass method and if that throws a SecurityException, catch it and display the appropriate dialog-- if the user presses OK, the method simply returns; if the user presses Cancel, the original SecurityException is thrown. (Also, previous responses for a given host are cached.) In the reported test case, the problem occurs when the RMI implementation internally (in the static initializer of the class sun.rmi.transport.tcp.TCPEndpoint) invokes InetAddress.getLocalHost, which happens to have peculiar security check behavior. Security-wise, InetAddress.getLocalHost requires permission to "resolve" the local host's name, which translates to an invocation of SecurityManager.checkConnect with the local host's name and -1 for the port number. But unlike most APIs that check security permissions, InetAddress.getLocalHost does not simply throw a SecurityException thrown by the security manager; instead, it catches such a SecurityException and (in that case) returns the InetAddress for the loopback address instead of bothering to look up the actual address. So one might think that it is innocuous to invoke InetAddress.getLocalHost in the sense that no lack of security permission will be exposed by it (except through its return value), but that is not the case from the security manager's perspective, from which it appears like any other attempt to resolve a host name. The RMI implementation really only needs to know the local host's address for "server" operations like exporting a remote object (it needs to know what address to put in the stub for an exported object)-- for "client"-only operations, like this test case is doing, the information is unnecessary. Therefore, it would seem reasonable to move this invocation of InetAddress.getLocalHost out of the static initializer for the internal TCPEndpoint class (which is used for both client- and server-oriented operations). (The RMI implementation's overall handling of the local host name/address for server operations could probably use some cleanup anyway.) Note that having the "java.rmi.server.hostname" system property set in the client VM should avoid this dialog (because it avoids the offending InetAddress.getLocalHost invocation), but presumably that system property cannot be configured through the JNLP file of an unsigned application.
14-03-2007