Derby
  1. Derby
  2. DERBY-2811

Specifying -h 0.0.0.0 with default security manager bars clients from connecting from any host

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: 10.3.1.4
    • Component/s: Network Server
    • Labels:
      None
    • Urgency:
      Blocker
    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Security

      Description

      The default policy file installed has this stanza:
      :
      permission java.net.SocketPermission "$

      {derby.drda.host}

      :*", "accept";
      :

      Normally, specifying -h 0.0.0.0 to NetworkServerControl lets clients connect
      from any host, but with the default policy file installed
      connecting fails even from localhost.

      I think this is because SocketPermission only recognizes "*" as a catch-all.

      1. derby-2811-04.diff
        2 kB
        Rick Hillegas
      2. derby-2811-03.diff
        0.7 kB
        Rick Hillegas
      3. derby-2811-02.diff
        10 kB
        Rick Hillegas
      4. derby-2811-01.diff
        18 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Daniel John Debrunner added a comment -

          I don't think it needs a release note, I assume you raise the question because the "Existing Application Impact" is checked?
          I think really this is (was) a regression, not existing application impact. But then it goes to not (yet) having a clear defintion of those fields.

          Show
          Daniel John Debrunner added a comment - I don't think it needs a release note, I assume you raise the question because the "Existing Application Impact" is checked? I think really this is (was) a regression, not existing application impact. But then it goes to not (yet) having a clear defintion of those fields.
          Hide
          Myrna van Lunteren added a comment -

          I closed this again, but does this need a Release Note?

          Show
          Myrna van Lunteren added a comment - I closed this again, but does this need a Release Note?
          Hide
          Daniel John Debrunner added a comment -

          Can the fix in version be set on this? Wasn't sure how it related to the timing of the branch so I didn't know what to set.

          Show
          Daniel John Debrunner added a comment - Can the fix in version be set on this? Wasn't sure how it related to the timing of the branch so I didn't know what to set.
          Hide
          Kathey Marsden added a comment -

          The IPV6 connection URL issue is logged as DERBY-526. The clash between the ':' url separator and the ':'s in the ip address is the issue.

          Show
          Kathey Marsden added a comment - The IPV6 connection URL issue is logged as DERBY-526 . The clash between the ':' url separator and the ':'s in the ip address is the issue.
          Hide
          Manjula Kutty added a comment -

          I did some basic Ipv6 testing before. and I could start the server on the Ipv6 machine using the syntax below

          java -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true org.apache.derby.drda.NetworkServerControl -h 2002:92a:8f7a:13:9:42:73:115 -p 1527

          and I got the connection through ij and using datasource. through ij i was connecting like this

          connect 'jdbc:derby://cranium-v6.rtp.raleigh.ibm.com:1527/ipv6db;create=true'; which works fine, but

          connect 'jdbc:derby://2002:92a:8f7a:13:9:42:73:115:1527/ipv6db;create=true';

          says syntax error for the hostname.

          ds.setServerName("2002:92a:8f7a:13:9:42:73:115"); works fine for the datasource.

          also I could do NetworkServerControl ping using both host name and ip address.

          The only thing I didn't try is using the security manager, which I will be doing for this Release

          Show
          Manjula Kutty added a comment - I did some basic Ipv6 testing before. and I could start the server on the Ipv6 machine using the syntax below java -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true org.apache.derby.drda.NetworkServerControl -h 2002:92a:8f7a:13:9:42:73:115 -p 1527 and I got the connection through ij and using datasource. through ij i was connecting like this connect 'jdbc:derby://cranium-v6.rtp.raleigh.ibm.com:1527/ipv6db;create=true'; which works fine, but connect 'jdbc:derby://2002:92a:8f7a:13:9:42:73:115:1527/ipv6db;create=true'; says syntax error for the hostname. ds.setServerName("2002:92a:8f7a:13:9:42:73:115"); works fine for the datasource. also I could do NetworkServerControl ping using both host name and ip address. The only thing I didn't try is using the security manager, which I will be doing for this Release
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Rick! Patch looks good!
          Does anyone know the state of Derby wrt to IPv6? SInce we are Java based I would
          expect that Derby should be able to handle this syntax, but we can address that in a separate issue
          if need be.

          Show
          Dag H. Wanvik added a comment - Thanks, Rick! Patch looks good! Does anyone know the state of Derby wrt to IPv6? SInce we are Java based I would expect that Derby should be able to handle this syntax, but we can address that in a separate issue if need be.
          Hide
          Rick Hillegas added a comment -

          Tests ran cleanly except for the error mentioned above. Committed derby-2811-04.diff at revision 547662.

          Show
          Rick Hillegas added a comment - Tests ran cleanly except for the error mentioned above. Committed derby-2811-04.diff at revision 547662.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-2811-04.diff. This eliminates redundant 0s in hostnames so that, say, "0.00.000.0" is equivalent to "0.0.0.0". I am running the tests now.

          I find that Derby does not accept "0:0:0:0:0:0:0:0" as a legal hostname, so I think this case can be skipped.

          Show
          Rick Hillegas added a comment - Attaching derby-2811-04.diff. This eliminates redundant 0s in hostnames so that, say, "0.00.000.0" is equivalent to "0.0.0.0". I am running the tests now. I find that Derby does not accept "0:0:0:0:0:0:0:0" as a legal hostname, so I think this case can be skipped.
          Hide
          Rick Hillegas added a comment -

          Commit derby-2811-03.diff at subversion revision 547527. This removes a debug diagnostic introduced by the previous submission.

          Show
          Rick Hillegas added a comment - Commit derby-2811-03.diff at subversion revision 547527. This removes a debug diagnostic introduced by the previous submission.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-2811-02.diff. This changes the hostname parameter to "derby.security.host" and maps the special host wildcard "::" to "*". Note that "::" is not accepted by Derby as a valid hostname, however. Tests passed except for the following diff, which also occurred in a clean client without this patch. Committed at subversion revision 547521.

          There was 1 error:
          1) parameterMetaDataJdbc30(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)java.lang.ClassNotFoundException: org.apache.derbyTesting.functionTests.tests.jdbcapi.parameterMetaDataJdbc30
          at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
          at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
          at java.lang.Class.forName0(Native Method)
          at java.lang.Class.forName(Class.java:141)
          at org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:83)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

          FAILURES!!!
          Tests run: 20, Failures: 0, Errors: 1

          Show
          Rick Hillegas added a comment - Attaching derby-2811-02.diff. This changes the hostname parameter to "derby.security.host" and maps the special host wildcard "::" to "*". Note that "::" is not accepted by Derby as a valid hostname, however. Tests passed except for the following diff, which also occurred in a clean client without this patch. Committed at subversion revision 547521. There was 1 error: 1) parameterMetaDataJdbc30(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)java.lang.ClassNotFoundException: org.apache.derbyTesting.functionTests.tests.jdbcapi.parameterMetaDataJdbc30 at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:83) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 20, Failures: 0, Errors: 1
          Hide
          Dag H. Wanvik added a comment -

          Checking up on IPv6 address syntax a bit, I see the
          unspecified address in IPv6 can also be legally written, say, as

          0:0:0:0:0:0:0:0 (preferred form)

          and in many other ways, I think, cf. http://www.faqs.org/rfcs/rfc2373.html, sec 2.2.

          The form "::" is a special syntax for a sequence of consecutive
          of zeros in an IPv6 address (can be used only once).

          The rfc mentions both "0:0:0:0:0:0:0:0" and "::" as examples on "unspecified address".

          For that matter, I guess even in IPv4, one could use leading zeros..
          000.000.000.000

          so for a safe recognition of "unspecified address" one would need to parse the IP address fully.

          Show
          Dag H. Wanvik added a comment - Checking up on IPv6 address syntax a bit, I see the unspecified address in IPv6 can also be legally written, say, as 0:0:0:0:0:0:0:0 (preferred form) and in many other ways, I think, cf. http://www.faqs.org/rfcs/rfc2373.html , sec 2.2. The form "::" is a special syntax for a sequence of consecutive of zeros in an IPv6 address (can be used only once). The rfc mentions both "0:0:0:0:0:0:0:0" and "::" as examples on "unspecified address". For that matter, I guess even in IPv4, one could use leading zeros.. 000.000.000.000 so for a safe recognition of "unspecified address" one would need to parse the IP address fully.
          Hide
          Dag H. Wanvik added a comment -

          Yes, using another property would be good, I think. I am less sure about
          your concrete name proposal: to me a host has a name (usually) and an address,
          and it the case of derby.drda.host one may give it a value of either a name or an IP address.
          This would be the case for this new property as well, so I would suggest
          something like derby.security.host.

          If I understand correctly, the new property, if not set, would default to the same value as
          derby.drda.host, possibly overridden by -h option,
          providing that isn't "0.0.0.0" or "::" (in which case one would translate it
          to "*"). That way existing apps would run unchanged, I think.

          Sounds good to me.

          Show
          Dag H. Wanvik added a comment - Yes, using another property would be good, I think. I am less sure about your concrete name proposal: to me a host has a name (usually) and an address, and it the case of derby.drda.host one may give it a value of either a name or an IP address. This would be the case for this new property as well, so I would suggest something like derby.security.host. If I understand correctly, the new property, if not set, would default to the same value as derby.drda.host, possibly overridden by -h option, providing that isn't "0.0.0.0" or "::" (in which case one would translate it to "*"). That way existing apps would run unchanged, I think. Sounds good to me.
          Hide
          Rick Hillegas added a comment -

          Thanks for the additional thoughts, Dag. Perhaps, we should not use derby.drda.host as the parameter name in the default policy file. Instead, we could use some parameter name like derby.host.address. We would forcibly set this variable and leave derby.drda.host alone.

          To summarize:

          1) In server.policy, we would change drda.host to derby.host.address. And derby.host.address would be the system property that the server forcibly sets

          2) We would set derby.host.adress to "*" if the customer specified the host as "0.0.0.0" or "::"

          Show
          Rick Hillegas added a comment - Thanks for the additional thoughts, Dag. Perhaps, we should not use derby.drda.host as the parameter name in the default policy file. Instead, we could use some parameter name like derby.host.address. We would forcibly set this variable and leave derby.drda.host alone. To summarize: 1) In server.policy, we would change drda.host to derby.host.address. And derby.host.address would be the system property that the server forcibly sets 2) We would set derby.host.adress to "*" if the customer specified the host as "0.0.0.0" or "::"
          Hide
          Dag H. Wanvik added a comment -

          Thanks for addressing this Rick!

          I think this patch fixes both DERBY-2811 and DERBY-2814, great.

          • There is possibly a bug still:

          It seems Derby supports IPv6, found this in the docs:

          //accepts connections from other hosts on an IPV6 system
          NetworkServerControl serverControl = new
          NetworkServerControl(InetAddress.getByName("::"),1527);

          So, it seems, if the user has an IPv6 system, she would give -h "::"
          and that might fail with SocketPermission in the same
          way as "0.0.0.0"?

          • Also, I think we should update the user docs with the fact that this
            automatics translation from "0.0.0.0"/"::" to "*" happens; some users
            might puzzle over it if they knew the SocketPermission syntax
            well.... And perhaps would try supplying Derby with a -h "*"
          • Question: When you set derby.drda.host finally (I had some problem
            understanding the comment's use of "force"), after Derby has created
            its socket and you have possibly change the syntax, so that the
            security manager will see the correct syntax when reading the policy
            file, the underlying premise is that Derby is done with using its
            value for socket creation purposes.

          There is code in the server which sends properties to the client,
          cf. NetworkServerControlImpl#sendPropInfo->getPropertyValues which
          reads the host value from hostArg, rather than from the current value
          of derby.drda.host, which is the right thing to do, since, hostArg
          has the correct syntax, but it is slightly confusing, since, at that
          point in time, the values of sent derby.drda.host (==hostArg) and
          server's derby.drda.host will have (possibly syntactically) different
          values. Would it perhaps be useful to reset the value of
          derby.drda.host to the Derby syntax after the security manager is
          done with (I guess you might need to temporarily set it again if
          refreshing the security file later though), so as to avoid confusion
          and possible bugs down the line?

          In short, let derby.drda.host only have the SocketPermission syntax
          temporarily when creating security manager and when reloading policy
          file.

          Or it should be the other way around, that after this point in
          time, the syntax will remain compliant with SocketPermission. Either
          way, I'd love the comment to explain this in some more detail. Maybe
          a comment in Property.java where DRDA_PROP_HOSTNAME is declared and on
          declaration of 'hostArg' is due as well.

          • I looked at the modified test and decorator but I need to read some
            more before I can comment on those changes.
          • Nits:
          • some lines > 80
          Show
          Dag H. Wanvik added a comment - Thanks for addressing this Rick! I think this patch fixes both DERBY-2811 and DERBY-2814 , great. There is possibly a bug still: It seems Derby supports IPv6, found this in the docs: //accepts connections from other hosts on an IPV6 system NetworkServerControl serverControl = new NetworkServerControl(InetAddress.getByName("::"),1527); So, it seems, if the user has an IPv6 system, she would give -h "::" and that might fail with SocketPermission in the same way as "0.0.0.0"? Also, I think we should update the user docs with the fact that this automatics translation from "0.0.0.0"/"::" to "*" happens; some users might puzzle over it if they knew the SocketPermission syntax well.... And perhaps would try supplying Derby with a -h "*" Question: When you set derby.drda.host finally (I had some problem understanding the comment's use of "force"), after Derby has created its socket and you have possibly change the syntax, so that the security manager will see the correct syntax when reading the policy file, the underlying premise is that Derby is done with using its value for socket creation purposes. There is code in the server which sends properties to the client, cf. NetworkServerControlImpl#sendPropInfo->getPropertyValues which reads the host value from hostArg, rather than from the current value of derby.drda.host, which is the right thing to do, since, hostArg has the correct syntax, but it is slightly confusing, since, at that point in time, the values of sent derby.drda.host (==hostArg) and server's derby.drda.host will have (possibly syntactically) different values. Would it perhaps be useful to reset the value of derby.drda.host to the Derby syntax after the security manager is done with (I guess you might need to temporarily set it again if refreshing the security file later though), so as to avoid confusion and possible bugs down the line? In short, let derby.drda.host only have the SocketPermission syntax temporarily when creating security manager and when reloading policy file. Or it should be the other way around, that after this point in time, the syntax will remain compliant with SocketPermission. Either way, I'd love the comment to explain this in some more detail. Maybe a comment in Property.java where DRDA_PROP_HOSTNAME is declared and on declaration of 'hostArg' is due as well. I looked at the modified test and decorator but I need to read some more before I can comment on those changes. Nits: some lines > 80
          Hide
          Rick Hillegas added a comment -

          Committed at subversion revision 547230.

          Show
          Rick Hillegas added a comment - Committed at subversion revision 547230.
          Hide
          Rick Hillegas added a comment -

          Attaching a patch for this problem: derby-2811-01.diff. Dag, could you take a gander at this? I will run tests later tonight. Touches the following files:

          M java/drda/org/apache/derby/drda/NetworkServerControl.java

          The special 0.0.0.0 Derby wildcard is translated into the * wildcard for poking into the system properties so that the vm can substitute * into the host variable in the default policy.

          M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SecureServerTest.java

          Added a test case for host 0.0.0.0.

          M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java

          Modified this decorator so that it can handle this edge case. Added some more defensive logic in places where exceptions were being silently swallowed. I noticed test hangs when running the new test case against a server without the changes to NetworkServerControl. After adding the defensive code, the tests don't hang anymore in that situation and SecureServerTest runs cleanly with the changes to NetworkServerControl. However, we should think more about how to handle unexpected ping errors in this decorator.

          Show
          Rick Hillegas added a comment - Attaching a patch for this problem: derby-2811-01.diff. Dag, could you take a gander at this? I will run tests later tonight. Touches the following files: M java/drda/org/apache/derby/drda/NetworkServerControl.java The special 0.0.0.0 Derby wildcard is translated into the * wildcard for poking into the system properties so that the vm can substitute * into the host variable in the default policy. M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SecureServerTest.java Added a test case for host 0.0.0.0. M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java Modified this decorator so that it can handle this edge case. Added some more defensive logic in places where exceptions were being silently swallowed. I noticed test hangs when running the new test case against a server without the changes to NetworkServerControl. After adding the defensive code, the tests don't hang anymore in that situation and SecureServerTest runs cleanly with the changes to NetworkServerControl. However, we should think more about how to handle unexpected ping errors in this decorator.
          Hide
          Kathey Marsden added a comment -

          I think this should be a blocker for 10.3 because of the high probability of existing application impact.

          Show
          Kathey Marsden added a comment - I think this should be a blocker for 10.3 because of the high probability of existing application impact.

            People

            • Assignee:
              Rick Hillegas
              Reporter:
              Dag H. Wanvik
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development