JDK-6534846 : Description of getByName method should be clarified
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2007-03-15
  • Updated: 2018-08-20
  • Resolved: 2018-08-20
Related Reports
Relates :  
JDK-6532906 - specification for getLocalHost() is too brief
Description
Specification for InetAddress.getByName() looks as followns:

-------------------------------
public static InetAddress getByName(String host)
                             throws UnknownHostException

    Determines the IP address of a host, given the host's name.

    The host name can either be a machine name, such as "java.sun.com", or a textual representation of its IP address. If a literal IP address is supplied, only the validity of the address format is checked.

    For host specified in literal IPv6 address, either the form defined in RFC 2732 or the literal IPv6 address format defined in RFC 2373 is accepted. IPv6 scoped addresses are also supported. See here for a description of IPv6 scoped addresses.

    If the host is null then an InetAddress representing an address of the loopback interface is returned. See RFC 3330 section 2 and RFC 2373 section 2.5.3.

    Parameters:
        host - the specified host, or null. 
    Returns:
        an IP address for the given host name. 
    Throws:
        UnknownHostException - if no IP address for the host could be found, or if a scope_id was specified for a global IPv6 address. 
        SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation
-------------------------------

So there are 2 possible modes for this method: 

* resolving address for symbolic name
* just factory method converting string representation of IP address into InetAddress instance

Check for security permission is reeasonable jsut for first mode and JDK behaves in such manner.  However, it is not clear from method specification that checkConnect should not be invoked for second mode.

This issue is applied to getAllByName() too.
Comments
EVALUATION It looks like there are 2 more issues which need clarification: 1. Currently JDK's behavior in case of "" passed to InetAddress.getByName() look equivalent to behavior with null passed as parameter however it is not specified. If such behavior is intentional then spec should be fixed (I think mentioning of emtpy string as reason to skip security check is not enough) 2. Currently JDK return loopback address even if there are no permissions at all. It contradicts with behavior of InetAddress.getLocalHost() and NetworkInterface.getInetAddresses() which do not allow to retrieve loopback address if there are no such permission. I don't know exactly which kind of behavior is more correct. However it looks like Java API should be consistent here.
27-03-2007
SUGGESTED FIX For both getByName() and getAllByName() ------------------------------------------- Throws: UnknownHostException - if no IP address for the host could be found. SecurityException - if a security manager exists, host name is not null or a literal IP address or an empty string and its checkConnect method doesn't allow the operation -------------------------------------------
26-03-2007
EVALUATION However you've misinterpreted it at first glance. Moreover you are not first from people involed in Java API who makes such misinterpretation. It looks like good indicator that specification is not clear. BTW, it is not obvious from phrase "If a literal IP address is supplied, only the validity of the address format is checked." that checkConnect is not invoked because nothing is said in main body of method specification about checkConnect and/or SecurityException: " Determines the IP address of a host, given the host's name. The host name can either be a machine name, such as "java.sun.com", or a textual representation of its IP address. If a literal IP address is supplied, only the validity of the address format is checked. For host specified in literal IPv6 address, either the form defined in RFC 2732 or the literal IPv6 address format defined in RFC 2373 is accepted. If the host is null then an InetAddress representing an address of the loopback interface is returned. See RFC 3330 section 2 and RFC 2373 section 2.5.3. " It is metioned just in throws part: " SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation " So it is quite possible to interpret it as "checkConnect is invoked first and then if SE is not thrown logic described in main body of method specification works". Moreover formally such interpretation looks most applicable. It can be rejected just from common sense standpoint. I think it makes sense to make specification more clear.
23-03-2007
SUGGESTED FIX Something like this: ------------------------------------------------------------- public static InetAddress getByName(String host) throws UnknownHostException Determines the IP address of a host, given the host's name. The host name can either be a machine name, such as "java.sun.com", or a textual representation of its IP address. If a literal IP address is supplied, only the validity of the address format is checked and no permissions are required from security manager in such case. For host specified in literal IPv6 address, either the form defined in RFC 2732 or the literal IPv6 address format defined in RFC 2373 is accepted. If the host is null then an InetAddress representing an address of the loopback interface is returned. See RFC 3330 section 2 and RFC 2373 section 2.5.3. Parameters: host - the specified host, or null. Returns: an IP address for the given host name. Throws: UnknownHostException - if no IP address for the host could be found. SecurityException - if a security manager exists, host name is not literal IP address and its checkConnect method doesn't allow the operation ---------------------------------------
23-03-2007
EVALUATION Okay, my first evaluation is not accurate enough. Actually the spec makes an exception for textual representation of IP address. It reads: ...If a literal IP address is supplied, only the validity of the address format is checked. So this is not a bug. Will close as 'not a defect'.
23-03-2007
EVALUATION However, JDK since 1.4.2 through 1.6 works accordingly with assumption provided in description of this CR. And it looks right because it is properties of environment which need to be protected not algorithm of converion String instance to InetAddress instance (which cab be written from scratch). Let look at following example: import java.net.*; public class GBN { public static void main(String[] args) throws Exception { System.out.println("GBN: " + InetAddress.getByName(args[0])); } } Let's take some named host: sr153295@qa-lin-02:~/work/sun/CDC/ipv6> ping bigblade.sfbay PING bigblade.sfbay.sun.com (10.5.29.202) 56(84) bytes of data. 64 bytes from bigblade.SFBay.Sun.COM (10.5.29.202): icmp_seq=1 ttl=243 time=210 ms 64 bytes from bigblade.SFBay.Sun.COM (10.5.29.202): icmp_seq=2 ttl=243 time=207 ms Let's run GBN without security manager installed: sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.6.0/linux-i586/bin/java GBN bigblade.sfbay GBN: bigblade.sfbay/10.5.29.202 sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.6.0/linux-i586/bin/java GBN 10.5.29.202 GBN: /10.5.29.202 Then let's run it with security manager and without any permission: sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.6.0/linux-i586/bin/java -Djava.security.manager GBN bigblade.sfbay Exception in thread "main" java.security.AccessControlException: access denied (java.net.SocketPermission bigblade.sfbay resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkConnect(SecurityManager.java:1031) at java.net.InetAddress.getAllByName0(InetAddress.java:1128) at java.net.InetAddress.getAllByName0(InetAddress.java:1109) at java.net.InetAddress.getAllByName(InetAddress.java:1072) at java.net.InetAddress.getByName(InetAddress.java:969) at GBN.main(GBN.java:6) sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.6.0/linux-i586/bin/java -Djava.security.manager GBN 10.5.29.202 GBN: /10.5.29.202 getByName invoked for literal address did not throw any exception. Let's try with JDK 1.5 and 1.4.2 sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.5/linux-i586/bin/java -Djava.security.manager GBN bigblade.sfbay Exception in thread "main" java.security.AccessControlException: access denied (java.net.SocketPermission bigblade.sfbay resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkConnect(SecurityManager.java:1031) at java.net.InetAddress.getAllByName0(InetAddress.java:1117) at java.net.InetAddress.getAllByName0(InetAddress.java:1098) at java.net.InetAddress.getAllByName(InetAddress.java:1061) at java.net.InetAddress.getByName(InetAddress.java:958) at GBN.main(GBN.java:6) sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.5/linux-i586/bin/java -Djava.security.manager GBN 10.5.29.202 GBN: /10.5.29.202 sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.4.2/linux-i586/bin/java -Djava.security.manager GBN bigblade.sfbay Exception in thread "main" java.security.AccessControlException: access denied (java.net.SocketPermission bigblade.sfbay resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkConnect(SecurityManager.java:1023) at java.net.InetAddress.getAllByName0(InetAddress.java:1000) at java.net.InetAddress.getAllByName0(InetAddress.java:981) at java.net.InetAddress.getAllByName(InetAddress.java:975) at java.net.InetAddress.getByName(InetAddress.java:889) at GBN.main(GBN.java:6) sr153295@qa-lin-02:~/work/sun/CDC/ipv6> /set/java/jdk1.4.2/linux-i586/bin/java -Djava.security.manager GBN 10.5.29.202 GBN: /10.5.29.202 The result is the same. So JDK assumes that for literal IP address no security checks needed. If accordingly with spec such checks are required it would mean bug in JDK. However behavior of JDK looks quite reasonable here. So it looks like spec should be clarified.
22-03-2007
EVALUATION The spec is clear about security check. checkConnect will be consulted regardless of whether it is a literal host name or a textual representation of IP address. I'm afraid of what the submitter asked is just speculation. This is not a bug.
22-03-2007