Bug 772212

Created attachment 551146 [details]
rmi hello example

i mean in the second case when you run the:
------------------------------------
./client 
HelloClient exception: java.rmi.ConnectException: Connection refused to host:
1.2.3.4; nested exception is: 
 java.net.ConnectException: Connection refused
------------------------------------
why when we use ip address everywhere? just because we use wrong hostname in
4.3.2.1.

this problem has a much longer consequence eg in case when we've more interface
on a host when we use route on a host etc...then rmi always can go into wrong
ip address and on wrong network interface etc. (it takes long for us to find
such and simple and easily reproducible example).

let's go further with the hello example!
change in the HelloServer to:
Naming.rebind("//127.0.0.1/hello1", stub);
then in the HelloClient use the ip address of the eth0 not the loopback:
HelloInterface hello = (HelloInterface)Naming.lookup("//4.3.2.1/hello1");
and it's still working!

IMHO it's not just a bug, but a serious security bug too! even it's nothing to do with redhat as it's probably a general java bug.

and probably has the same reason as all of the above...

(In reply to comment #4)
> let's go further with the hello example!
> change in the HelloServer to:
> Naming.rebind("//127.0.0.1/hello1", stub);
> then in the HelloClient use the ip address of the eth0 not the loopback:
> HelloInterface hello = (HelloInterface)Naming.lookup("//4.3.2.1/hello1");
> and it's still working!
> 
> IMHO it's not just a bug, but a serious security bug too! even it's nothing to
> do with redhat as it's probably a general java bug.
> 

Seems like this bit's intentional.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4880793 explains it as:

--- being quote ---
By default, an RMI registry (such as one created with the LocateRegistry.createRegistry API), or any other exported remote object, receives calls on a server socket that is bound to all local network interfaces-- in IPv4 notation, for example, it is bound to the wildcard address 0.0.0.0.  (This is why the client described in the report can reach the registry in order to perform a lookup.)

[ It is possible to create a registry that receives calls on a server socket bound to a specific local network interface, if binding to all of them is not desired: this can be achieved by passing a custom RMIServerSocketFactory to the LocateRegistry.createRegistry method.  This technique is described in the following RMI-USERS thread:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0306&L=rmi-users&P=1805 ]
--- end quote ---

The final link, like most *sun.com links, is broken :/

Oh, I forgot to ask, are any of these problems new? Or can you reproduce them with older java-1.6.0-openjdk packages? Do they also occur with Sun/Oracle's java?

i don't know. we just test one of our much more complicated problem and after we find these simple example. and we only test it with the latest redhat's java-1.6.0-openjdk package.
anyway 1 and 3 still valid bug.

it's seems to be a feature not a bug:-(
after i read all kind of java doc it's turn out that neither bind nor lookup has not any effect of the ip address written into the host part. ie. it's _only_ locate the machine, but rmiregistry do not bind use the ip address at all.
imho it's a very bad design decision and it'd have to be changed (but i assume it'll never happened). unfortunately currently there is no way to change the java.rmi.server.hostname just to restart
rmiregistry -J-Djava.rmi.server.hostname=...
which is required if eg. a vpn ip adddress changed by the underlying os layer.
but this is unusable if more object binded and they don't know each other:-(

Hi Levente,

From what I gather you reported two problems:

1. RMI uses hostnames internally instead of (the more correct) ip addresses. As you noted in comment 8, this is a design limitation.

2. RMI exports objects to 0.0.0.0 instead of a specific ip address. As described in comment 5, this is also an intentionally designed feature.

Given that these are both design issues and fixing them would require major changes, possibly large divergence from upstream and perhaps even breaking compatibility, I am going to close this as WONTFIX.

Fee free to re-open this if needed.

both of your point seems to true, but i don't know whether these are  "intentionally designed feature" or bugs...