Derby
  1. Derby
  2. DERBY-2874

NetworkServer not accepting connections with default security manager on Ipv6 machines

    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, 10.4.1.3
    • Component/s: Network Server
    • Labels:
      None
    • Environment:
      Ipv6 machine with ibm jvm 15
    • Bug behavior facts:
      Regression, Security

      Description

      While running tests on Ipv6 machines using the 10.3 jars with the default security manager, I had the following findings/questions
      I started the server like this java org.apache.derby.drda.NetworkServerControl start -h 2002:92a:8f7a:13:9:42:74:19
      and the server started with the following command
      Security manager installed using the Basic server security policy.
      Apache Derby Network Server - 10.3.1.0 beta - (548006) started and ready to accept connections on port 1527 at 2007-06-25 23:44: 36.835 GMT

      So I think the server is using the default security manager. Then when I tried to get conenction though ij

      got the following error message
      Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34016 accept,resolve)
      java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34016 accept,resolve)
      at java.security.AccessController.checkPermission(AccessController.java:104)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
      at java.lang.SecurityManager.checkAccept (SecurityManager.java:1172)
      at java.net.ServerSocket.implAccept(ServerSocket.java:466)
      at java.net.ServerSocket.accept(ServerSocket.java:433)
      at org.apache.derby.impl.drda.ClientThread$1.run (Unknown Source)
      at java.security.AccessController.doPrivileged(AccessController.java:242)
      at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)

      I had the derby.properties file like this

      derby.database.sqlAuthorization=true
      derby.connection.requireAuthentication=true
      derby.infolog.append=true
      derby.authentication.provider=BUILTIN
      derby.stream.error.logSeverityLevel=0

      #derby.language.logStatementText=true

      1. User's Definitions
        derby.user.user2=pass2
      1. derby-2874-04-bracketsAllPorts.diff
        3 kB
        Rick Hillegas
      2. derby-2874-03.diff
        3 kB
        Rick Hillegas
      3. derby-2874-wildcard-02.diff
        4 kB
        Rick Hillegas
      4. derby-2874-wildcard-01.diff
        1.0 kB
        Rick Hillegas
      5. server.policy
        2 kB
        Manjula Kutty
      6. derby-2874-01.diff
        0.5 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Attaching patch which removes the wildcarded port spec from the default socket permission. Would appreciate it if someone with access to an ipv6 machine could try this out. thanks.

          Show
          Rick Hillegas added a comment - Attaching patch which removes the wildcarded port spec from the default socket permission. Would appreciate it if someone with access to an ipv6 machine could try this out. thanks.
          Hide
          Manjula Kutty added a comment -

          Here is the e-mail thread regarding this issue

          http://www.nabble.com/Derby-on-Ipv6-tf3979831.html#a11298151

          Show
          Manjula Kutty added a comment - Here is the e-mail thread regarding this issue http://www.nabble.com/Derby-on-Ipv6-tf3979831.html#a11298151
          Hide
          Manjula Kutty added a comment -

          I tried with Rick's patch and Still has the problem. Here is the new stack trace

          2007-06-26 18:23:02.674 GMT Thread[main,5,main] java.security.AccessControlException: Access denied (java.io.FilePermission derby.log read)
          Apache Derby Network Server - 10.3.1.0 beta - (548006) started and ready to accept connections on port 1527 at 2007-06-26 18:23:02.730 GMT
          Apache Derby Network Server - 10.3.1.0 beta - (548006) started and ready to accept connections on port 1527 at 2007-06-26 18:23:02.730 GMT
          Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34040 ac cept,resolve)
          Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34040 ac cept,resolve)
          java.security.AccessControlException: Access denied (java.net.SocketPermission [ 2002:92a:8f7a:13:9:42:73:218]:34040 accept,resolve)
          at java.security.AccessController.checkPermission(AccessController.java: 104)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
          at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172)
          at java.net.ServerSocket.implAccept(ServerSocket.java:466)
          at java.net.ServerSocket.accept(ServerSocket.java:433)
          at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source)
          at java.security.AccessController.doPrivileged(AccessController.java:242 )
          at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)
          java.security.AccessControlException: Access denied (java.net.SocketPermission [ 2002:92a:8f7a:13:9:42:73:218]:34040 accept,resolve)
          at java.security.AccessController.checkPermission(AccessController.java: 104)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
          at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172)
          at java.net.ServerSocket.implAccept(ServerSocket.java:466)
          at java.net.ServerSocket.accept(ServerSocket.java:433)
          at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source)
          at java.security.AccessController.doPrivileged(AccessController.java:242 )
          at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)

          After getting this error, to the same server (didn't restart), I tried connecting from another machine to the same server got communication error. Here is the error message on the client machine for that

          ERROR 58009: A communications error has been detected: Connection reset.

          Show
          Manjula Kutty added a comment - I tried with Rick's patch and Still has the problem. Here is the new stack trace 2007-06-26 18:23:02.674 GMT Thread [main,5,main] java.security.AccessControlException: Access denied (java.io.FilePermission derby.log read) Apache Derby Network Server - 10.3.1.0 beta - (548006) started and ready to accept connections on port 1527 at 2007-06-26 18:23:02.730 GMT Apache Derby Network Server - 10.3.1.0 beta - (548006) started and ready to accept connections on port 1527 at 2007-06-26 18:23:02.730 GMT Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218] :34040 ac cept,resolve) Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218] :34040 ac cept,resolve) java.security.AccessControlException: Access denied (java.net.SocketPermission [ 2002:92a:8f7a:13:9:42:73:218]:34040 accept,resolve) at java.security.AccessController.checkPermission(AccessController.java: 104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172) at java.net.ServerSocket.implAccept(ServerSocket.java:466) at java.net.ServerSocket.accept(ServerSocket.java:433) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:242 ) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) java.security.AccessControlException: Access denied (java.net.SocketPermission [ 2002:92a:8f7a:13:9:42:73:218]:34040 accept,resolve) at java.security.AccessController.checkPermission(AccessController.java: 104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172) at java.net.ServerSocket.implAccept(ServerSocket.java:466) at java.net.ServerSocket.accept(ServerSocket.java:433) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:242 ) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) After getting this error, to the same server (didn't restart), I tried connecting from another machine to the same server got communication error. Here is the error message on the client machine for that ERROR 58009: A communications error has been detected: Connection reset.
          Hide
          Manjula Kutty added a comment -

          Here is the policy file I used. Also this is the command I used to start the server

          [[root@incus mkutty]# java -Djava.security.manager -Djava.security.policy=/usr/mkutty/server.policy org.apache.derby.drda.NetworkServerControl start -h 2002:92a: 8f7a:13:9:42:74:19

          Show
          Manjula Kutty added a comment - Here is the policy file I used. Also this is the command I used to start the server [ [root@incus mkutty] # java -Djava.security.manager -Djava.security.policy=/usr/mkutty/server.policy org.apache.derby.drda.NetworkServerControl start -h 2002:92a: 8f7a:13:9:42:74:19
          Hide
          Rick Hillegas added a comment -

          Thanks for running this experiment, Manjula. I'm a little unclear on what test you tried. The command line above indicates that you installed your own security manager and used your own policy file. The policy file you used has unsubstutited parameters in it. It doesn't appear as though any of those parameters are declared on your command line, so the VM won't substitute them. That would explain why you have now lost file permissions as well as the socket permission. Those parameters are forced to reasonable values by the server only if the server decides that it needs to install its own security manager and default policy file.

          Could you try the following experiments:

          1) In your server policy file, replace the parameters with good values. So for instance,

          $

          {derby.install.url}

          would be replaced with something like file:///export/home/rh161140/derby/mainline/trunk/jars/sane/
          $

          {derby.system.home}

          would be replaced with something like /export/home/rh161140/derby/mainline
          $

          {derby.security.host}

          would be replaced with the host address you use as the -h argument on your command line

          Since you are running with your own policy file you will probably also need to add the following permission to the rights granted to derby.jar:

          permission java.util.PropertyPermission "user.dir", "read";

          2) In the second experiment, it would be great if you could apply the patch to your workspace and build the jar files. Then use those jar files to run the original test which you described in your first mail message--that is, just bring boot the server with your port specification but without declaring a security manager or policy file. This should force the server to install its own security manager and pick up the new default policy file (which is the only change introduced by the patch).

          Thanks!

          Show
          Rick Hillegas added a comment - Thanks for running this experiment, Manjula. I'm a little unclear on what test you tried. The command line above indicates that you installed your own security manager and used your own policy file. The policy file you used has unsubstutited parameters in it. It doesn't appear as though any of those parameters are declared on your command line, so the VM won't substitute them. That would explain why you have now lost file permissions as well as the socket permission. Those parameters are forced to reasonable values by the server only if the server decides that it needs to install its own security manager and default policy file. Could you try the following experiments: 1) In your server policy file, replace the parameters with good values. So for instance, $ {derby.install.url} would be replaced with something like file:///export/home/rh161140/derby/mainline/trunk/jars/sane/ $ {derby.system.home} would be replaced with something like /export/home/rh161140/derby/mainline $ {derby.security.host} would be replaced with the host address you use as the -h argument on your command line Since you are running with your own policy file you will probably also need to add the following permission to the rights granted to derby.jar: permission java.util.PropertyPermission "user.dir", "read"; 2) In the second experiment, it would be great if you could apply the patch to your workspace and build the jar files. Then use those jar files to run the original test which you described in your first mail message--that is, just bring boot the server with your port specification but without declaring a security manager or policy file. This should force the server to install its own security manager and pick up the new default policy file (which is the only change introduced by the patch). Thanks!
          Hide
          Manjula Kutty added a comment -

          Tried with the patch and using the default security manager.

          started the server with the command:

          [root@incus pantry]# java org.apache.derby.drda.NetworkServerControl start -h 2002:92a:8f7a:13:9:42:74:19

          And the stack trace is

          Security manager installed using the Basic server security policy.
          Apache Derby Network Server - 10.3.1.1 beta - (550927M) started and ready to accept connections on port 1527 at 2007-06-26 20:40:16.862 GMT
          Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34047 accept,resolve)
          java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34047 accept,resolve)
          at java.security.AccessController.checkPermission(AccessController.java:104)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
          at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172)
          at java.net.ServerSocket.implAccept(ServerSocket.java:466)
          at java.net.ServerSocket.accept(ServerSocket.java:433)
          at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source)
          at java.security.AccessController.doPrivileged(AccessController.java:242)
          at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)
          Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115]:1241 accept,resolve)
          java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115]:1241 accept,resolve)
          at java.security.AccessController.checkPermission(AccessController.java:104)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
          at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172)
          at java.net.ServerSocket.implAccept(ServerSocket.java:466)
          at java.net.ServerSocket.accept(ServerSocket.java:433)
          at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source)
          at java.security.AccessController.doPrivileged(AccessController.java:242)
          at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)
          Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115]:1242 accept,resolve)
          java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115]:1242 accept,resolve)
          at java.security.AccessController.checkPermission(AccessController.java:104)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
          at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172)
          at java.net.ServerSocket.implAccept(ServerSocket.java:466)
          at java.net.ServerSocket.accept(ServerSocket.java:433)
          at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source)
          at java.security.AccessController.doPrivileged(AccessController.java:242)
          at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)

          Show
          Manjula Kutty added a comment - Tried with the patch and using the default security manager. started the server with the command: [root@incus pantry] # java org.apache.derby.drda.NetworkServerControl start -h 2002:92a:8f7a:13:9:42:74:19 And the stack trace is Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.3.1.1 beta - (550927M) started and ready to accept connections on port 1527 at 2007-06-26 20:40:16.862 GMT Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218] :34047 accept,resolve) java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218] :34047 accept,resolve) at java.security.AccessController.checkPermission(AccessController.java:104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172) at java.net.ServerSocket.implAccept(ServerSocket.java:466) at java.net.ServerSocket.accept(ServerSocket.java:433) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:242) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115] :1241 accept,resolve) java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115] :1241 accept,resolve) at java.security.AccessController.checkPermission(AccessController.java:104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172) at java.net.ServerSocket.implAccept(ServerSocket.java:466) at java.net.ServerSocket.accept(ServerSocket.java:433) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:242) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115] :1242 accept,resolve) java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:115] :1242 accept,resolve) at java.security.AccessController.checkPermission(AccessController.java:104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1172) at java.net.ServerSocket.implAccept(ServerSocket.java:466) at java.net.ServerSocket.accept(ServerSocket.java:433) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:242) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)
          Hide
          Rick Hillegas added a comment -

          Attaching derby-2874-wildcard-01.diff. This grants accept permission to the wildcard address "*".

          Manjul, thanks for sticking with this issue. Could you try experiment (2) with this patch?

          Show
          Rick Hillegas added a comment - Attaching derby-2874-wildcard-01.diff. This grants accept permission to the wildcard address "*". Manjul, thanks for sticking with this issue. Could you try experiment (2) with this patch?
          Hide
          Manjula Kutty added a comment -

          Rick,

          With this patch I could get connection to the server using default security manager. But by looking at the policy file I got this doubt , are we giving permission to everyone?

          By removing the "$

          {derby.security.host}

          I feel now the server is less secure.

          I don't know much about the security and policy. This is what I felt. If we are not loosing any intended security by doing this patch, then I would like to get this fix done on the 10.3 release candidate.

          Show
          Manjula Kutty added a comment - Rick, With this patch I could get connection to the server using default security manager. But by looking at the policy file I got this doubt , are we giving permission to everyone? By removing the "$ {derby.security.host} I feel now the server is less secure. I don't know much about the security and policy. This is what I felt. If we are not loosing any intended security by doing this patch, then I would like to get this fix done on the 10.3 release candidate.
          Hide
          Rick Hillegas added a comment -

          Thanks for test-driving this patch, Manjula. It also works for me on my personal laptop, which runs a version of Suse with dual v4 and v6 protocol stacks.

          I think that it would be better to restrict the socket permission as much as possible just as it would be better to restrict the file permissions as much as possible. However, I think this more liberal socket permission is fine for the default policy just as the liberal file permission is ok. The liberal socket permission is only granted to derbynet.jar and the server limits itself to addresses specified at boot time. Socket permission continues to be denied to code outside the server, such as user-written functions and procedures.

          Show
          Rick Hillegas added a comment - Thanks for test-driving this patch, Manjula. It also works for me on my personal laptop, which runs a version of Suse with dual v4 and v6 protocol stacks. I think that it would be better to restrict the socket permission as much as possible just as it would be better to restrict the file permissions as much as possible. However, I think this more liberal socket permission is fine for the default policy just as the liberal file permission is ok. The liberal socket permission is only granted to derbynet.jar and the server limits itself to addresses specified at boot time. Socket permission continues to be denied to code outside the server, such as user-written functions and procedures.
          Hide
          Daniel John Debrunner added a comment -

          Is it not possible to set derby.security.host to the correct format for the policy file when using an IPv6 address?
          From looking at the error message and some brief googling it looks like the address should be enclosed in square brackets.

          Show
          Daniel John Debrunner added a comment - Is it not possible to set derby.security.host to the correct format for the policy file when using an IPv6 address? From looking at the error message and some brief googling it looks like the address should be enclosed in square brackets.
          Hide
          Rick Hillegas added a comment -

          Attaching new version of the patch, derby-2874-wildcard-02.diff. In addition to wildcarding the socket permission, this patch removes the now unused code which calculated a value for derby.security.host. Touches the following files:

          M java/engine/org/apache/derby/iapi/reference/Property.java
          M java/drda/org/apache/derby/drda/NetworkServerControl.java

          Removes logic which calculated a value for security.host.property.

          M java/drda/org/apache/derby/drda/server.policy
          M java/drda/org/apache/derby/drda/template.policy

          Wildcards the socket permission.

          Show
          Rick Hillegas added a comment - Attaching new version of the patch, derby-2874-wildcard-02.diff. In addition to wildcarding the socket permission, this patch removes the now unused code which calculated a value for derby.security.host. Touches the following files: M java/engine/org/apache/derby/iapi/reference/Property.java M java/drda/org/apache/derby/drda/NetworkServerControl.java Removes logic which calculated a value for security.host.property. M java/drda/org/apache/derby/drda/server.policy M java/drda/org/apache/derby/drda/template.policy Wildcards the socket permission.
          Hide
          Rick Hillegas added a comment -

          Dan asks:

          >Is it not possible to set derby.security.host to the correct format for the policy file when using an IPv6 address?
          >From looking at the error message and some brief googling it looks like the address should be enclosed in square brackets.

          It's possible. I think the devil is in the details and I'm worried about edge cases this close to the release date. We could log a new JIRA to improve this.

          Show
          Rick Hillegas added a comment - Dan asks: >Is it not possible to set derby.security.host to the correct format for the policy file when using an IPv6 address? >From looking at the error message and some brief googling it looks like the address should be enclosed in square brackets. It's possible. I think the devil is in the details and I'm worried about edge cases this close to the release date. We could log a new JIRA to improve this.
          Hide
          Daniel John Debrunner added a comment -

          > It's possible. I think the devil is in the details and I'm worried about edge cases this close to the release date. We could log a new JIRA to improve this.

          Probably it's just me, but I'd be more worried about a late security change with little security analysis rather than handling a formatting change that can be tested with a handful of cases (8?, hostname, ip address, localhost, all addresses for IPv4 & IPv6).

          Show
          Daniel John Debrunner added a comment - > It's possible. I think the devil is in the details and I'm worried about edge cases this close to the release date. We could log a new JIRA to improve this. Probably it's just me, but I'd be more worried about a late security change with little security analysis rather than handling a formatting change that can be tested with a handful of cases (8?, hostname, ip address, localhost, all addresses for IPv4 & IPv6).
          Hide
          Rick Hillegas added a comment -

          Regardless of whether we (1) log a follow-on JIRA or (2) try to set derby.security.host in this release, it would be good to understand what extra security holes are covered by (2). What are your thoughts?

          Show
          Rick Hillegas added a comment - Regardless of whether we (1) log a follow-on JIRA or (2) try to set derby.security.host in this release, it would be good to understand what extra security holes are covered by (2). What are your thoughts?
          Hide
          Manjula Kutty added a comment -

          In my personal openion I will go for option 2. Also I have the access to the Ipv6 machines for a limited time. So even if we go for option 1 , we may not be able to test it on the Ipv6 machinessoon after the fix.

          Show
          Manjula Kutty added a comment - In my personal openion I will go for option 2. Also I have the access to the Ipv6 machines for a limited time. So even if we go for option 1 , we may not be able to test it on the Ipv6 machinessoon after the fix.
          Hide
          Rick Hillegas added a comment -

          I am happy to write a new patch so that we can experiment with (2) as long as Manjula can help test this. First, I would like to figure out what the behavior should be. Is it the following? In this discussion originalHostAddress means the value of the -h option or the value of derby.drda.host.

          A) If originalHostAddress evaluates to the same socket as the wildcard "0.0.0.0" or is the ipv6 wildcard "::", then set derby.security.host to the socket wildcard "*"

          B) Otherwise, if originalHostAddress is composed entirely of hex digits and colons and InetAddress.getByName( originalHostAddress ) is an Inet6Address, then bracket originalHostAddress with [] and set derby.security.host to that bracketed value.

          C) Otherwise, set derby.security.host to originalHostAddress.

          Show
          Rick Hillegas added a comment - I am happy to write a new patch so that we can experiment with (2) as long as Manjula can help test this. First, I would like to figure out what the behavior should be. Is it the following? In this discussion originalHostAddress means the value of the -h option or the value of derby.drda.host. A) If originalHostAddress evaluates to the same socket as the wildcard "0.0.0.0" or is the ipv6 wildcard "::", then set derby.security.host to the socket wildcard "*" B) Otherwise, if originalHostAddress is composed entirely of hex digits and colons and InetAddress.getByName( originalHostAddress ) is an Inet6Address, then bracket originalHostAddress with [] and set derby.security.host to that bracketed value. C) Otherwise, set derby.security.host to originalHostAddress.
          Hide
          Daniel John Debrunner added a comment -

          What's the benefit of A), isn't the functionality covered by B) and C)?

          Show
          Daniel John Debrunner added a comment - What's the benefit of A), isn't the functionality covered by B) and C)?
          Hide
          Rick Hillegas added a comment -

          We could eliminate (A) and see what happens. It's a case which was put in to handle DERBY-2811.

          Show
          Rick Hillegas added a comment - We could eliminate (A) and see what happens. It's a case which was put in to handle DERBY-2811 .
          Hide
          Daniel John Debrunner added a comment -

          OK on A). I didn't know about the issue seen in DERBY-2811

          Show
          Daniel John Debrunner added a comment - OK on A). I didn't know about the issue seen in DERBY-2811
          Hide
          Rick Hillegas added a comment -

          Attaching derby-2874-03.diff. This implements (2) as described in steps (A) - (C). Touches the following files:

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

          Implements steps (A) - (C)

          M java/drda/org/apache/derby/drda/server.policy
          M java/drda/org/apache/derby/drda/template.policy

          Same as in derby-2874-02.diff, i.e., removes wildcarded port specification

          Show
          Rick Hillegas added a comment - Attaching derby-2874-03.diff. This implements (2) as described in steps (A) - (C). Touches the following files: M java/drda/org/apache/derby/drda/NetworkServerControl.java Implements steps (A) - (C) M java/drda/org/apache/derby/drda/server.policy M java/drda/org/apache/derby/drda/template.policy Same as in derby-2874-02.diff, i.e., removes wildcarded port specification
          Hide
          Daniel John Debrunner added a comment -

          Is there a reference for putting the ipv6 address in square brackets, apart from my comment above?
          Just wondered if some research had gone in this or you just trusted my brief comment?
          My searching was very quick, early morning and before coffee

          Show
          Daniel John Debrunner added a comment - Is there a reference for putting the ipv6 address in square brackets, apart from my comment above? Just wondered if some research had gone in this or you just trusted my brief comment? My searching was very quick, early morning and before coffee
          Hide
          Rick Hillegas added a comment -

          Right, I assumed you had swallowed more coffee than I had. There's the javadoc for SocketPermission: http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketPermission.html It indicates that the address should be bracketed. However, it also calls for tacking on a port spec, after the bracketed address. I'm wondering whether we need to wildcard the port spec and end up with something like "[0:1:2:3:4]:0-" I'm out of my depth here.

          Show
          Rick Hillegas added a comment - Right, I assumed you had swallowed more coffee than I had. There's the javadoc for SocketPermission: http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketPermission.html It indicates that the address should be bracketed. However, it also calls for tacking on a port spec, after the bracketed address. I'm wondering whether we need to wildcard the port spec and end up with something like " [0:1:2:3:4] :0-" I'm out of my depth here.
          Hide
          Daniel John Debrunner added a comment - - edited

          Thanks Rick, I never saw that. I may now have had more coffee than you, I don't see anything that calls for "tacking on a port spec", seems optional in every thing I read there. Could you quote whatever leads you to believe that. Thanks.

          Show
          Daniel John Debrunner added a comment - - edited Thanks Rick, I never saw that. I may now have had more coffee than you, I don't see anything that calls for "tacking on a port spec", seems optional in every thing I read there. Could you quote whatever leads you to believe that. Thanks.
          Hide
          Rick Hillegas added a comment -

          Thanks, Dan. You're right, the javadoc says "The port or portrange is optional." I don't see an explicit statement of what meaning is attached to a SocketPermission which doesn't have a port spec. However, I'm having a hard time imagining any meaning other than "all ports on that host".

          Show
          Rick Hillegas added a comment - Thanks, Dan. You're right, the javadoc says "The port or portrange is optional." I don't see an explicit statement of what meaning is attached to a SocketPermission which doesn't have a port spec. However, I'm having a hard time imagining any meaning other than "all ports on that host".
          Hide
          Manjula Kutty added a comment -

          Thanks for the new patch Rick. But unfortunatly I'm still getting the same error with the same stack trace.

          Show
          Manjula Kutty added a comment - Thanks for the new patch Rick. But unfortunatly I'm still getting the same error with the same stack trace.
          Hide
          Rick Hillegas added a comment -

          Thanks for testing that last patch, Manjula. I'm attaching another patch, derby-2874-04-bracketsAllPorts.diff. This patch adds ":0-" to the end of the bracketed host address on the off chance that the port spec needs to be wildcarded. I am running out of ideas!

          Show
          Rick Hillegas added a comment - Thanks for testing that last patch, Manjula. I'm attaching another patch, derby-2874-04-bracketsAllPorts.diff. This patch adds ":0-" to the end of the bracketed host address on the off chance that the port spec needs to be wildcarded. I am running out of ideas!
          Hide
          Manjula Kutty added a comment -

          Hi Rick,

          No more ideas needed. This patch works fine...

          Show
          Manjula Kutty added a comment - Hi Rick, No more ideas needed. This patch works fine...
          Hide
          Rick Hillegas added a comment -

          Thanks for sticking with this, Manjula. Unless someone objects, I intend to commit the derby-2874-04-bracketsAllPorts.diff patch this afternoon (San Francisco time).

          Show
          Rick Hillegas added a comment - Thanks for sticking with this, Manjula. Unless someone objects, I intend to commit the derby-2874-04-bracketsAllPorts.diff patch this afternoon (San Francisco time).
          Hide
          Rick Hillegas added a comment -

          Committed derby-2874-bracketsAllPorts.diff at subversion revision 552977.

          Show
          Rick Hillegas added a comment - Committed derby-2874-bracketsAllPorts.diff at subversion revision 552977.
          Hide
          Rick Hillegas added a comment -

          P:orted previous submission to 10.3 branch at subversion revision 552981.

          Show
          Rick Hillegas added a comment - P:orted previous submission to 10.3 branch at subversion revision 552981.

            People

            • Assignee:
              Rick Hillegas
              Reporter:
              Manjula Kutty
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development