Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6471977

Caching namelookup with Security Manager doesn't work as documented

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Not an Issue
    • Affects Version/s: 5.0u10
    • Fix Version/s: 5.0u10
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      The customer have found an interesting behaviour, that they can
      reproduce on both Windows and Solaris with Java 5.0. While at
      first this looks like an OS-level name service issue, deeper
      investigation suggests this is indeed a Java problem - either
      a docs or a functionality bug.

      They describe:

      -------- Forwarded Message --------

      I'm executing the following program:

      public class SecMgr {

          public static void main(String[] args) throws Exception{
              while(true){
              InetAddress i = InetAddress.getByName(args[0]);
              System.out.println(i.toString());
                  Thread.currentThread().sleep(2000);
              }
          }
      }

      A) with networkaddress.cache.ttl (java.security) set to -1
      B) with networkaddress.cache.ttl (java.security) set to 0
      C) with networkaddress.cache.ttl (java.security) set to 0 and
      java.security.manager property set (thus installing the default java
      security manager)

      According to the documentation in the java.security file, case A and
      case C should warrant the same behaviour X, where as B should exhibit
      behaviour Y.

      Behaviour X:
      Changing the underlying OS configuration to return different ip
      addresses for certain host names, should not be reflected in the JVM
      since the entries in the "Java-level namelookup cache" are cached
      forever (they are never refreshed).

      Behaviour Y:
      Changing the underlying OS configuration to return different ip
      addresses for certain host names, should be reflected in the JVM since
      the entries in the "Java-level namelookup cache" are not cached at all
      and are retrieved from the OS each time.

      To simulate this behaviour (under Solaris and Windows) the entries of
      the /etc/hosts or c:/OS/system32/drivers/etc/hosts files respectively
      are adapted while the test program is executed. (Solaris' nssswitch.conf
      is configured "hosts: file dns").

      Contradicting the documentation in the java.security file, even when a
      security manager is installed, case C exhibits behaviour Y.

      Isn't this a plain documentation bug in the java.security file or is the
      DNS Cache (referred to as Java-level namelookup cache) not behaving as
      expected, when installing a security manager?

        Attachments

          Activity

            People

            Assignee:
            chegar Chris Hegarty
            Reporter:
            mbowyer Mark Bowyer (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: