Bug 772212 - another java rmi bug
another java rmi bug
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: java-1.6.0-openjdk (Show other bugs)
6.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Deepak Bhole
BaseOS QE - Apps
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-06 08:31 EST by Levente Farkas
Modified: 2012-01-10 06:29 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-09 15:03:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
rmi hello example (2.28 KB, application/x-compressed-tar)
2012-01-06 08:34 EST, Levente Farkas
no flags Details

  None (edit)
Description Levente Farkas 2012-01-06 08:31:24 EST
after you fix the rmiregistry bug we found a few other, but probably related to each other has the same source.

let's we use the same Hello rmi example as in the previous case.

bug 1:
let we'va machine on the lan with ip 1.2.3.4 and hostname test.example.com where the dns resolve 1.2.3.4 to test.example.com and back test.example.com to 1.2.3.4. then create another host which has different ip (of course) eg. 4.3.2.1, but put into the /etc/sysconfig/network 
HOSTNAME=test.example.com
ie. the other host's name.
then edit the HelloServer.java and put 4.3.2.1 into the 
Naming.rebind("//4.3.2.1/hello1", stub);
ie. the real ip address of the second host. 
then run wireshark on the first host 1.2.3.4.
then run on the second:
./compile
./server
and you will see 4.3.2.1 connect to 1.2.3.4. why???
probably that's the main reason of all other problems.
ie. if i only use ip address everywhere in my code why java resolve the the ip and connect to that host? what try to do?

bug 2: the real problem happened when we use a third host as a client (with any valid ip and hostname and and you edit this line to the second host:
HelloInterface hello = (HelloInterface)Naming.lookup("//4.3.2.1/hello1");
then why this is not working and why try to connect to 1.2.3.4???
Comment 1 Levente Farkas 2012-01-06 08:34:22 EST
Created attachment 551146 [details]
rmi hello example
Comment 3 Levente Farkas 2012-01-06 08:45:13 EST
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).
Comment 4 Levente Farkas 2012-01-06 11:24:47 EST
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...
Comment 5 Omair Majid 2012-01-06 16:14:31 EST
(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 :/
Comment 6 Omair Majid 2012-01-06 16:16:21 EST
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?
Comment 7 Levente Farkas 2012-01-06 19:55:49 EST
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.
Comment 8 Levente Farkas 2012-01-09 06:42:55 EST
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:-(
Comment 9 Omair Majid 2012-01-09 15:03:12 EST
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.
Comment 10 Levente Farkas 2012-01-10 06:29:31 EST
both of your point seems to true, but i don't know whether these are  "intentionally designed feature" or bugs...

Note You need to log in before you can comment on or make changes to this bug.