Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 326835 - [RemoteSrvc] Hostnames default to "localhost"
Summary: [RemoteSrvc] Hostnames default to "localhost"
Status: RESOLVED FIXED
Alias: None
Product: ECF
Classification: RT
Component: ecf.remoteservices (show other bugs)
Version: 3.3.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.5.0   Edit
Assignee: ecf.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 303979 326841 328542
Blocks:
  Show dependency tree
 
Reported: 2010-10-02 06:47 EDT by Markus Kuppe CLA
Modified: 2011-03-01 13:44 EST (History)
2 users (show)

See Also:


Attachments
Skype discussion for reference (7.47 KB, text/plain)
2010-10-02 06:48 EDT, Markus Kuppe CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Kuppe CLA 2010-10-02 06:47:15 EDT
Based on a Skype discussion, the reasons for picking "localhost" are (+ == pro localhost, - == IP determined by /etc/hosts):

+ A service provider can overwrite the default with an ECF specific property upon service registration (org.eclipse.ecf.osgi.services.distribution.IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS)
- This sort of configuration should be determined dynamically. Either via system properties, configadmin or InetAddress.getLocalhost()... if they are strictly necessary in the first place. A service provider certainly does not want to make this decision/configuration during service registration. Especially since the arguments are RemoteServiceContainer specific and the currently active container is not known to the service provider during service registration.

+ InetAddress.getLocalhost().getHostName()/.getHostAddress is a non-reliable way to determine the public IP address
- It is the defined way to determine a host address/host name (in Java). It uses the system wide configuration which e.g. comes from /etc/hosts or DHCP. Why duplicate this kind of configuration into a (static) ECF specific property?

+ registering a service with the public IP address exposes a security risk
- Binding a RemoteServiceContainer to 0.0.0.0 instead of 127.0.0.1 is the security risk. Setting the service endpointId to "127.0.0.1" does not enhance security significantly as any skilled attacker will simple do a port scan.

+ production system need configuration anyway
- Administrators will usually set up /etc/hosts correctly or use dynamic means of configuration (DHCP)

+ dual homed devices need extra configuration
- This is not the default (yet) and thus KISS should be applied

So what are the possible implementations:

a) Do not register host containers automatically (see bug #303979 for counter arguments)
b) Create containers automatically, but by default only bind the RemoteServiceContainer to the loopback interface (while printing a warning/info). However, hostname(s) should not be hardcoded to "localhost" but determined dynamically:
b1) via InetAddress.getLocalhost().getHost*()
b2) System properties
b3) OSGi Configadmin
c) Create containers automatically and bind them to 0.0.0.0 (b1-3 apply here too).

Whatever we decide upon, behavior should be consistent across providers.
Comment 1 Markus Kuppe CLA 2010-10-02 06:48:27 EDT
Created attachment 180100 [details]
Skype discussion for reference
Comment 2 Markus Kuppe CLA 2010-10-02 07:41:44 EDT
FWIW: 

- r-OSGi currently does not work with IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS set to anything else but "r-osgi:// + hostname that points to current host (localhost|public ip|public hostname) + "9278" as the r-osgi bundle creates the endpoint based on system properties/defaults for port/InetAddress (this is related to bug #267521).

- generic correctly works with a URI of e.g. "osgiservices://" + public hostname + "12345:" + "/foobar"
Comment 3 Markus Kuppe CLA 2010-10-24 04:45:40 EDT
Changing target to 3.5 since this won't be addressed in time for 3.4
Comment 4 Scott Lewis CLA 2011-03-01 13:44:49 EST
I'm resolving this bug, as I think we've done what we can on this issue in the short term.  If others have contributions to do things in better/easier way (e.g. one of the options listed in the original bug report) then either reopen this bug and attach the contribution (or express intentions about doing contribution), or open a new enhancement request.