Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-6438

Explicitly grant SocketPermission "listen" in default server policy

    Details

    • Urgency:
      Normal
    • Issue & fix info:
      Release Note Needed

      Description

      The network server needs SocketPermission "listen" on the port that it listens to, but this permission is not granted by the basic server policy that's installed by default. This doesn't cause any problems in most cases, since the JVM's default policy grants all code bases SocketPermission "listen" on a range of ports, and Derby's network server port is within that range.

      Still, the network server should not rely on this fact. It is possible to run the network server on any port, not only those ports that happen be in the range that's given carte blanche by the platform's default policy. The network server will however not be able to run on those ports with the basic policy currently, only with a custom policy or with the security manager disabled.

      The default policy should make this permission explicit.

      1. 1010_server.policy
        10 kB
        Rick Hillegas
      2. 1010_server.policy
        10 kB
        Rick Hillegas
      3. 1010_server.policy
        10 kB
        Rick Hillegas
      4. 1010_server.policy
        10 kB
        Myrna van Lunteren
      5. d6438-1a.diff
        23 kB
        Knut Anders Hatlen
      6. releaseNote.html
        8 kB
        Knut Anders Hatlen
      7. releaseNote.html
        8 kB
        Myrna van Lunteren

        Activity

        Hide
        knutanders Knut Anders Hatlen added a comment -

        For example, if you attempt to start a network server that listens to a port number lower than 1024 (given that the user has the required OS privileges to listen to such ports), the network server will fail on startup:

        $ java -jar derbynet.jar start -p 1000
        Thu Dec 19 11:56:26 CET 2013 : Security manager installed using the Basic server security policy.
        Thu Dec 19 11:56:27 CET 2013 : access denied ("java.net.SocketPermission" "localhost:1000" "listen,resolve")
        java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:1000" "listen,resolve")
        	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
        	at java.security.AccessController.checkPermission(AccessController.java:559)
        	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        	at java.lang.SecurityManager.checkListen(SecurityManager.java:1137)
        	at java.net.ServerSocket.bind(ServerSocket.java:375)
        	at java.net.ServerSocket.<init>(ServerSocket.java:237)
        	at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
        	at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(NetworkServerControlImpl.java:698)
        	at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(NetworkServerControlImpl.java:94)
        	at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:748)
        	at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:745)
        	at java.security.AccessController.doPrivileged(Native Method)
        	at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:744)
        	at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277)
        	at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353)
        
        Show
        knutanders Knut Anders Hatlen added a comment - For example, if you attempt to start a network server that listens to a port number lower than 1024 (given that the user has the required OS privileges to listen to such ports), the network server will fail on startup: $ java -jar derbynet.jar start -p 1000 Thu Dec 19 11:56:26 CET 2013 : Security manager installed using the Basic server security policy. Thu Dec 19 11:56:27 CET 2013 : access denied ("java.net.SocketPermission" "localhost:1000" "listen,resolve") java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:1000" "listen,resolve") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) at java.security.AccessController.checkPermission(AccessController.java:559) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkListen(SecurityManager.java:1137) at java.net.ServerSocket.bind(ServerSocket.java:375) at java.net.ServerSocket.<init>(ServerSocket.java:237) at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231) at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(NetworkServerControlImpl.java:698) at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(NetworkServerControlImpl.java:94) at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:748) at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:745) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:744) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277) at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353)
        Hide
        knutanders Knut Anders Hatlen added a comment -

        The attached patch d6438-1a.diff adds the following permission to the default server policy:

          // Allow the server to listen to the socket on the port specified with the
          // -p option to "NetworkServerControl start" on the command line, or with
          // the portNumber parameter to the NetworkServerControl constructor in the
          // API, or with the property derby.drda.portNumber. The default is 1527.
          permission java.net.SocketPermission "localhost:${derby.security.port}",
              "listen";
        

        It also adds some code to NetworkServerControl so that ${derby.security.port} gets replaced by the actual port that the network server is going to listen on.

        This change made it possible to start a network server on any port in my environment.

        Additionally, the patch states the listen permission explicitly in the test policy files. With that change, I was able to run suites.All with derby.tests.basePort=1000, which would fail miserably without the patch.

        I've also verified that the full regression test suite runs cleanly without the derby.tests.basePort property.

        Show
        knutanders Knut Anders Hatlen added a comment - The attached patch d6438-1a.diff adds the following permission to the default server policy: // Allow the server to listen to the socket on the port specified with the // -p option to "NetworkServerControl start" on the command line, or with // the portNumber parameter to the NetworkServerControl constructor in the // API, or with the property derby.drda.portNumber. The default is 1527. permission java.net.SocketPermission "localhost:${derby.security.port}" , "listen" ; It also adds some code to NetworkServerControl so that ${derby.security.port } gets replaced by the actual port that the network server is going to listen on. This change made it possible to start a network server on any port in my environment. Additionally, the patch states the listen permission explicitly in the test policy files. With that change, I was able to run suites.All with derby.tests.basePort=1000, which would fail miserably without the patch. I've also verified that the full regression test suite runs cleanly without the derby.tests.basePort property.
        Hide
        rhillegas Rick Hillegas added a comment -

        Thanks, Knut. These changes look good to me. +1

        Show
        rhillegas Rick Hillegas added a comment - Thanks, Knut. These changes look good to me. +1
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1553081 from Knut Anders Hatlen in branch 'code/trunk'
        [ https://svn.apache.org/r1553081 ]

        DERBY-6438: Explicitly grant SocketPermission "listen" in default server policy

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1553081 from Knut Anders Hatlen in branch 'code/trunk' [ https://svn.apache.org/r1553081 ] DERBY-6438 : Explicitly grant SocketPermission "listen" in default server policy
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1554997 from Myrna van Lunteren in branch 'code/branches/10.10'
        [ https://svn.apache.org/r1554997 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        backport of revision 1553081 from trunk

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1554997 from Myrna van Lunteren in branch 'code/branches/10.10' [ https://svn.apache.org/r1554997 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy backport of revision 1553081 from trunk
        Hide
        myrna Myrna van Lunteren added a comment -

        It is my understanding that it is up to the JVM to decide what range of ports to specify - is that correct?
        In any case, I needed this backported to 10.10, so I did. Would there be an objection to backporting it further?

        Show
        myrna Myrna van Lunteren added a comment - It is my understanding that it is up to the JVM to decide what range of ports to specify - is that correct? In any case, I needed this backported to 10.10, so I did. Would there be an objection to backporting it further?
        Hide
        knutanders Knut Anders Hatlen added a comment -

        It is my understanding that it is up to the JVM to decide what range of ports to specify - is that correct?

        That's my understanding too.

        In any case, I needed this backported to 10.10, so I did. Would there be an objection to backporting it further?

        I don't see any problems with that.

        Thanks.

        Show
        knutanders Knut Anders Hatlen added a comment - It is my understanding that it is up to the JVM to decide what range of ports to specify - is that correct? That's my understanding too. In any case, I needed this backported to 10.10, so I did. Would there be an objection to backporting it further? I don't see any problems with that. Thanks.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1556068 from Myrna van Lunteren in branch 'code/branches/10.9'
        [ https://svn.apache.org/r1556068 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        backport of revision 1554997 from 10.10

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1556068 from Myrna van Lunteren in branch 'code/branches/10.9' [ https://svn.apache.org/r1556068 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy backport of revision 1554997 from 10.10
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1556267 from Myrna van Lunteren in branch 'code/branches/10.8'
        [ https://svn.apache.org/r1556267 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        backport of revision 1556068 from 10.9

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1556267 from Myrna van Lunteren in branch 'code/branches/10.8' [ https://svn.apache.org/r1556267 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy backport of revision 1556068 from 10.9
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1556368 from Myrna van Lunteren in branch 'code/branches/10.7'
        [ https://svn.apache.org/r1556368 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        backport of revision 1556267 from 10.8

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1556368 from Myrna van Lunteren in branch 'code/branches/10.7' [ https://svn.apache.org/r1556368 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy backport of revision 1556267 from 10.8
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1556796 from Knut Anders Hatlen in branch 'code/branches/10.6'
        [ https://svn.apache.org/r1556796 ]

        DERBY-6438: Explicitly grant SocketPermission "listen" in default server policy

        Merged revision 1556368 from 10.7.

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1556796 from Knut Anders Hatlen in branch 'code/branches/10.6' [ https://svn.apache.org/r1556796 ] DERBY-6438 : Explicitly grant SocketPermission "listen" in default server policy Merged revision 1556368 from 10.7.
        Hide
        knutanders Knut Anders Hatlen added a comment -

        Thanks for backporting the fix, Myrna. I got a request for this fix on 10.6, so I did that backport myself (it merged cleanly from 10.7).

        Are you planning to backport it any further? If not, I'll mark the issue as resolved.

        Show
        knutanders Knut Anders Hatlen added a comment - Thanks for backporting the fix, Myrna. I got a request for this fix on 10.6, so I did that backport myself (it merged cleanly from 10.7). Are you planning to backport it any further? If not, I'll mark the issue as resolved.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1556909 from Myrna van Lunteren in branch 'code/branches/10.5'
        [ https://svn.apache.org/r1556909 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        merge of revision 1556796 from 10.6

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1556909 from Myrna van Lunteren in branch 'code/branches/10.5' [ https://svn.apache.org/r1556909 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy merge of revision 1556796 from 10.6
        Hide
        myrna Myrna van Lunteren added a comment -

        Backported to 10.5, which is as far as I intend to take it.

        Show
        myrna Myrna van Lunteren added a comment - Backported to 10.5, which is as far as I intend to take it.
        Hide
        myrna Myrna van Lunteren added a comment - - edited

        I would like to see a release note for this one. There is an (Oracle, and picked up by IBM) JVM security change that requests or suggests removal or limitation of the 'range of ports' on which JVMS by default grant the "listen" permission. I cannot find details about this JVM change, but as a result of it, users that have (unknowingly) relied on this in the past will now have to modify their policy files, or Network Server will no longer work.

        I think a release note will be useful to draw attention to it.

        Show
        myrna Myrna van Lunteren added a comment - - edited I would like to see a release note for this one. There is an (Oracle, and picked up by IBM) JVM security change that requests or suggests removal or limitation of the 'range of ports' on which JVMS by default grant the "listen" permission. I cannot find details about this JVM change, but as a result of it, users that have (unknowingly) relied on this in the past will now have to modify their policy files, or Network Server will no longer work. I think a release note will be useful to draw attention to it.
        Hide
        knutanders Knut Anders Hatlen added a comment -

        The JVM security change is described in the JDK 7u51 release notes under the header "Change in Default Socket Permissions": http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html

        The JDK release notes also have a more specific section about the problems this change causes for the Derby network server (look for "Additional permission needed to run Java DB network server") and how to resolve them. The Derby release note for this issue could probably contain much of the same information.

        Show
        knutanders Knut Anders Hatlen added a comment - The JVM security change is described in the JDK 7u51 release notes under the header "Change in Default Socket Permissions": http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html The JDK release notes also have a more specific section about the problems this change causes for the Derby network server (look for "Additional permission needed to run Java DB network server") and how to resolve them. The Derby release note for this issue could probably contain much of the same information.
        Hide
        myrna Myrna van Lunteren added a comment -

        Thanks for that link, Knut...Here's an attempt at a release note for this issue.
        Review will be appreciated.
        If OK, this issue can be resolved again.

        Show
        myrna Myrna van Lunteren added a comment - Thanks for that link, Knut...Here's an attempt at a release note for this issue. Review will be appreciated. If OK, this issue can be resolved again.
        Hide
        knutanders Knut Anders Hatlen added a comment -

        Thanks for writing the release note, Myrna. It looks good to me.

        I'm uploading an updated version with some small adjustments: I replaced a couple of occurrences of "Java DB" with "Derby", and also fixed up some minor issues with nesting of UL and LI elements reported by org.apache.derbyBuild.ReleaseNoteReader.

        Show
        knutanders Knut Anders Hatlen added a comment - Thanks for writing the release note, Myrna. It looks good to me. I'm uploading an updated version with some small adjustments: I replaced a couple of occurrences of "Java DB" with "Derby", and also fixed up some minor issues with nesting of UL and LI elements reported by org.apache.derbyBuild.ReleaseNoteReader.
        Hide
        myrna Myrna van Lunteren added a comment -

        Attaching a copy of the updated server.policy (renamed to 1010_server.policy) as convenience for users using 10.10 and hitting this issue.

        Show
        myrna Myrna van Lunteren added a comment - Attaching a copy of the updated server.policy (renamed to 1010_server.policy) as convenience for users using 10.10 and hitting this issue.
        Hide
        myrna Myrna van Lunteren added a comment -

        Thanks Knut, I didn't get around to running the release note checker yet... The updated file looks good to me. I'll resolve this issue again.

        Show
        myrna Myrna van Lunteren added a comment - Thanks Knut, I didn't get around to running the release note checker yet... The updated file looks good to me. I'll resolve this issue again.
        Hide
        rhillegas Rick Hillegas added a comment -

        Attaching an updated version of the 1010_server.policy. I have confirmed that the old version flunks the server boot on JDK 7 and higher as reported on this derby-user thread: http://apache-database.10148.n7.nabble.com/Network-Server-Access-Permissions-and-Java-1-7-0-51-td136583.html. The old version was missing a permissions block which is needed for managing extra file access controls on JDK 7 and higher. With the new policy file, I am able to boot the server and create an in-memory database using Java 1.8.0-ea-b121.

        Show
        rhillegas Rick Hillegas added a comment - Attaching an updated version of the 1010_server.policy. I have confirmed that the old version flunks the server boot on JDK 7 and higher as reported on this derby-user thread: http://apache-database.10148.n7.nabble.com/Network-Server-Access-Permissions-and-Java-1-7-0-51-td136583.html . The old version was missing a permissions block which is needed for managing extra file access controls on JDK 7 and higher. With the new policy file, I am able to boot the server and create an in-memory database using Java 1.8.0-ea-b121.
        Hide
        rhillegas Rick Hillegas added a comment -

        Attaching a third version of 1010_server.policy. The previous version included customizations to point the codebases at my file system. The third version uses variables to point at the codebases instead.

        Show
        rhillegas Rick Hillegas added a comment - Attaching a third version of 1010_server.policy. The previous version included customizations to point the codebases at my file system. The third version uses variables to point at the codebases instead.
        Hide
        rhillegas Rick Hillegas added a comment -

        Attaching another version of 1010_server.policy. I found that the previous version allowed me to boot the server and create on-disk databases using Derby 10.10.1.1. However, when I tried to bring down the server like this...

        java org.apache.derby.drda.NetworkServerControl shutdown -p 8246 -user \"rick\" -password rickspassword

        ...the server crashed with this error...

        java.security.AccessControlException: access denied ("java.sql.SQLPermission" "deregisterDriver")
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457)
        at java.security.AccessController.checkPermission(AccessController.java:884)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.sql.DriverManager.deregisterDriver(DriverManager.java:402)
        at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(Unknown Source)
        at org.apache.derby.jdbc.Driver20.stop(Unknown Source)
        at org.apache.derby.impl.services.monitor.TopService.stop(Unknown Source)
        at org.apache.derby.impl.services.monitor.TopService.shutdown(Unknown Source)
        at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
        at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
        at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
        at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
        at org.apache.derby.jdbc.EmbeddedDriver.connect(Unknown Source)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source)
        at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)

        The "deregisterDriver" permission is needed if you are running on JDK 8. The new version of 1010_server.policy adds the following permission to the derby engine and the derby server. With this extra permission, the 10.10.1.1 server comes down gracefully on JDK 8...

        permission java.sql.SQLPermission "deregisterDriver";

        Show
        rhillegas Rick Hillegas added a comment - Attaching another version of 1010_server.policy. I found that the previous version allowed me to boot the server and create on-disk databases using Derby 10.10.1.1. However, when I tried to bring down the server like this... java org.apache.derby.drda.NetworkServerControl shutdown -p 8246 -user \"rick\" -password rickspassword ...the server crashed with this error... java.security.AccessControlException: access denied ("java.sql.SQLPermission" "deregisterDriver") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:402) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(Unknown Source) at org.apache.derby.jdbc.Driver20.stop(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.stop(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.shutdown(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source) at org.apache.derby.jdbc.Driver20.connect(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.connect(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source) at org.apache.derby.drda.NetworkServerControl.main(Unknown Source) The "deregisterDriver" permission is needed if you are running on JDK 8. The new version of 1010_server.policy adds the following permission to the derby engine and the derby server. With this extra permission, the 10.10.1.1 server comes down gracefully on JDK 8... permission java.sql.SQLPermission "deregisterDriver";
        Hide
        chaase3 Kim Haase added a comment -

        I should reopen DERBY-6448 and add that deregisterDriver permission to the policy, right? Currently it's only in the Dev Guide for the embedded driver.

        Show
        chaase3 Kim Haase added a comment - I should reopen DERBY-6448 and add that deregisterDriver permission to the policy, right? Currently it's only in the Dev Guide for the embedded driver.
        Hide
        rhillegas Rick Hillegas added a comment -

        Hi Kim: That sounds right to me. Thanks.

        Show
        rhillegas Rick Hillegas added a comment - Hi Kim: That sounds right to me. Thanks.
        Hide
        myrna Myrna van Lunteren added a comment -

        Thanks Rick, for updating the policy file...
        John, I hope you can let us know if this now works.

        Kim, It seems to me that the documenting of the deregister policy as something needed also for network server belongs with DERBY-6239, I think you should add it there...

        I think the JVM vendors are wrong in requiring permissions within the live of a version, but I guess that's just me.

        And that opens up the question if we should leave this discussion at this bug, modify the default policy file in 10.10 to match the changes Rick made, or backport DERBY-6224 altogether. And back to what version - presumably 10.8 when we started supporting Java 7. Or is this functionality also affecting older Derby versions?

        Opinions?

        Show
        myrna Myrna van Lunteren added a comment - Thanks Rick, for updating the policy file... John, I hope you can let us know if this now works. Kim, It seems to me that the documenting of the deregister policy as something needed also for network server belongs with DERBY-6239 , I think you should add it there... I think the JVM vendors are wrong in requiring permissions within the live of a version, but I guess that's just me. And that opens up the question if we should leave this discussion at this bug, modify the default policy file in 10.10 to match the changes Rick made, or backport DERBY-6224 altogether. And back to what version - presumably 10.8 when we started supporting Java 7. Or is this functionality also affecting older Derby versions? Opinions?
        Hide
        chaase3 Kim Haase added a comment -

        You're right, Myrna – I reopened DERBY-6239. Thanks.

        Show
        chaase3 Kim Haase added a comment - You're right, Myrna – I reopened DERBY-6239 . Thanks.
        Hide
        rhillegas Rick Hillegas added a comment -

        Hi Myrna,

        The "deregisterDriver" permission was introduced in Java 8. It looks like DERBY-6224 was backported to 10.9. I suppose that it makes sense backporting DERBY-6224 to older Derby branches if we think that releases from those branches will be run on Java 8. Thanks.

        Show
        rhillegas Rick Hillegas added a comment - Hi Myrna, The "deregisterDriver" permission was introduced in Java 8. It looks like DERBY-6224 was backported to 10.9. I suppose that it makes sense backporting DERBY-6224 to older Derby branches if we think that releases from those branches will be run on Java 8. Thanks.
        Hide
        myrna Myrna van Lunteren added a comment -

        Thanks for checking on that Rick...
        I am confused though - John Moore did not have Java 8, he used Java 7 with u7_51 (' 1.7.0_51'), right?
        So, maybe he did not need the deregister permission after all?

        Show
        myrna Myrna van Lunteren added a comment - Thanks for checking on that Rick... I am confused though - John Moore did not have Java 8, he used Java 7 with u7_51 (' 1.7.0_51'), right? So, maybe he did not need the deregister permission after all?
        Hide
        rhillegas Rick Hillegas added a comment -

        Hi Myrna,

        That's right. John didn't need the deregisterDriver permission on Java 7. But I noticed that I needed it when I ran 10.10.1.1 on Java 8. 10.10.1.1 is supposed to run on Java 8. The change to the JVM which broke Derby will appear in Java 8 also. To keep things simple for our users, I think we should stick to your original plan of publishing one 1010_server.policy which works on all JVMs. Thanks.

        Show
        rhillegas Rick Hillegas added a comment - Hi Myrna, That's right. John didn't need the deregisterDriver permission on Java 7. But I noticed that I needed it when I ran 10.10.1.1 on Java 8. 10.10.1.1 is supposed to run on Java 8. The change to the JVM which broke Derby will appear in Java 8 also. To keep things simple for our users, I think we should stick to your original plan of publishing one 1010_server.policy which works on all JVMs. Thanks.
        Hide
        mikem Mike Matrigali added a comment - - edited

        I also agree we should put out a single server policy file in 10.10 that works for as many jvms as possible. If policy files allow, it would be nice to add a comment in the file noting the param is new for jdk18 and above but should be ok to include when using releases previous to jdk18 and will have no affect (i assume). This will be good to get into the upcoming 10.10 apache release will be targeted at full support of jdk18 when it is actually released.

        the question for those of us wanting to support the newest pre-jdk18 releases coming from oracle now (and from dependent vendors in the near future) on derby releases prior to 10.10, is what exactly do we need to backport to address this new issue.

        Show
        mikem Mike Matrigali added a comment - - edited I also agree we should put out a single server policy file in 10.10 that works for as many jvms as possible. If policy files allow, it would be nice to add a comment in the file noting the param is new for jdk18 and above but should be ok to include when using releases previous to jdk18 and will have no affect (i assume). This will be good to get into the upcoming 10.10 apache release will be targeted at full support of jdk18 when it is actually released. the question for those of us wanting to support the newest pre-jdk18 releases coming from oracle now (and from dependent vendors in the near future) on derby releases prior to 10.10, is what exactly do we need to backport to address this new issue.
        Hide
        myrna Myrna van Lunteren added a comment -

        The file attached to this issue is only intended as a convenience for our users using jdk 1.7 u51 - or jdk 18, until we have an official Apache 10.10.(2) release with the fixes in the default policyfile in it.

        I admit I did not test before attaching the file straight from the codebase, I assumed it would work because I thought this is the same policy file that works as the default policy file included in derbynet.jar

        But it was not working as work-around, when you issue the command suggested:
        java -Djava.security.manager -Djava.security.policy=[filename] org.apache.derby.drda.NetworkServerControl start&
        you got this error:
        java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write")

        This permission is apparently not needed in the default policy file.

        Rick modified the 1010_server.policy workaround file by adding this permission, and then went on to add some further permissions needed to get it working under jdk18 - specifically the deregister permission. This puzzles me too - it seemed from the original notes that this was only needed for embedded.

        And I am still puzzled, I now also got myself jdk17u51, but I cannot get the command to work with the policy file, even though it has the "derby.__serverStartedFromCmdLine" permission that it's complaining about...I have tried modifying my CLASSPATH to have just derbyrun.jar, and to have derbyclient.jar;derbynet.jar, but I get the same effect...?
        I added the permission to the various codebases in the workaround file (derbyclient.jar, derby.jar, derbytools.jar, derbynet.jar) and still get the same...
        I must be doing something wrong, but what...

        Show
        myrna Myrna van Lunteren added a comment - The file attached to this issue is only intended as a convenience for our users using jdk 1.7 u51 - or jdk 18, until we have an official Apache 10.10.(2) release with the fixes in the default policyfile in it. I admit I did not test before attaching the file straight from the codebase, I assumed it would work because I thought this is the same policy file that works as the default policy file included in derbynet.jar But it was not working as work-around, when you issue the command suggested: java -Djava.security.manager -Djava.security.policy= [filename] org.apache.derby.drda.NetworkServerControl start& you got this error: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write") This permission is apparently not needed in the default policy file. Rick modified the 1010_server.policy workaround file by adding this permission, and then went on to add some further permissions needed to get it working under jdk18 - specifically the deregister permission. This puzzles me too - it seemed from the original notes that this was only needed for embedded. And I am still puzzled, I now also got myself jdk17u51, but I cannot get the command to work with the policy file, even though it has the "derby.__serverStartedFromCmdLine" permission that it's complaining about...I have tried modifying my CLASSPATH to have just derbyrun.jar, and to have derbyclient.jar;derbynet.jar, but I get the same effect...? I added the permission to the various codebases in the workaround file (derbyclient.jar, derby.jar, derbytools.jar, derbynet.jar) and still get the same... I must be doing something wrong, but what...
        Hide
        knutanders Knut Anders Hatlen added a comment -

        But it was not working as work-around, when you issue the command suggested:
        java -Djava.security.manager -Djava.security.policy=[filename] org.apache.derby.drda.NetworkServerControl start&
        you got this error:
        java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write")

        This permission is apparently not needed in the default policy file.

        That's correct. This property is set by NetworkServerControl's main() method before the default security policy is installed, so it doesn't need any permissions to set the property in that case. In the case where we enable the security manager on the command line, the security manager is already installed when this code gets executed, and the permission is required in order to set the property.

        So it seems as if this permission is needed if and only if all of the following statements are true:

        1. The server is started from the command line
        2. A custom security policy is installed
        3. The Java version is 1.7 or higher

        Rick modified the 1010_server.policy workaround file by adding this permission, and then went on to add some further permissions needed to get it working under jdk18 - specifically the deregister permission. This puzzles me too - it seemed from the original notes that this was only needed for embedded.

        On head of trunk and the branches to which DERBY-6224 has been backported, the deregisterDriver permission should not be needed by the network server policy, since server shutdown uses the deregister=false attribute when it shuts down the engine. Furthermore, the engine shutdown code was changed so that the lack of this permission did not make shutdown fail. Instead, it just writes a message to derby.log saying it couldn't deregister the driver.

        Since 10.10.1.1 doesn't have any of those fixes, it sounds reasonable to add that permission to the suggested custom policy attached to this issue. I don't think it should be added to the default server policy in future versions, though.

        Show
        knutanders Knut Anders Hatlen added a comment - But it was not working as work-around, when you issue the command suggested: java -Djava.security.manager -Djava.security.policy=[filename] org.apache.derby.drda.NetworkServerControl start& you got this error: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write") This permission is apparently not needed in the default policy file. That's correct. This property is set by NetworkServerControl's main() method before the default security policy is installed, so it doesn't need any permissions to set the property in that case. In the case where we enable the security manager on the command line, the security manager is already installed when this code gets executed, and the permission is required in order to set the property. So it seems as if this permission is needed if and only if all of the following statements are true: The server is started from the command line A custom security policy is installed The Java version is 1.7 or higher Rick modified the 1010_server.policy workaround file by adding this permission, and then went on to add some further permissions needed to get it working under jdk18 - specifically the deregister permission. This puzzles me too - it seemed from the original notes that this was only needed for embedded. On head of trunk and the branches to which DERBY-6224 has been backported, the deregisterDriver permission should not be needed by the network server policy, since server shutdown uses the deregister=false attribute when it shuts down the engine. Furthermore, the engine shutdown code was changed so that the lack of this permission did not make shutdown fail. Instead, it just writes a message to derby.log saying it couldn't deregister the driver. Since 10.10.1.1 doesn't have any of those fixes, it sounds reasonable to add that permission to the suggested custom policy attached to this issue. I don't think it should be added to the default server policy in future versions, though.
        Hide
        knutanders Knut Anders Hatlen added a comment -

        And I am still puzzled, I now also got myself jdk17u51, but I cannot get the command to work with the policy file, even though it has the "derby.__serverStartedFromCmdLine" permission that it's complaining about...

        The 1010_server.policy file cannot be used directly as it is. It has to be customized for the environment in which it is used. One has to replace occurrences of ${derby.install.url} with the actual location of the jar files (on the form file:///path/to/derby) and ${derby.security.port} with the port that the network server will be listening on (typically 1527).

        Show
        knutanders Knut Anders Hatlen added a comment - And I am still puzzled, I now also got myself jdk17u51, but I cannot get the command to work with the policy file, even though it has the "derby.__serverStartedFromCmdLine" permission that it's complaining about... The 1010_server.policy file cannot be used directly as it is. It has to be customized for the environment in which it is used. One has to replace occurrences of ${derby.install.url} with the actual location of the jar files (on the form file:///path/to/derby ) and ${derby.security.port} with the port that the network server will be listening on (typically 1527).
        Hide
        myrna Myrna van Lunteren added a comment - - edited

        Thanks Knut for the explanations.

        I probably should have grabbed the template.policy file from the source code anyway - that one works without changes if I pass the correct parameter for derby.install.url.

        And I did figure out what I was doing wrong, mostly mistyping the url path for the 'derby.install.url' property. For a while I missed the final '/', in a long path i.e., in the end I passed in
        -Dderby.install.url=file:///c:/[blahblahetc]/1010jars
        instead of
        -Dderby.install.url=file:///c:/[blahblahetc]/1010jars/
        so it never found the jar files.

        Also, I had trouble with the number of slashes after the file url protocol identifier.
        One, or three worked:
        -Dderby.install.url=file:///c:/jars/1010jars/
        -Dderby.install.url=file:/c:/jars/1010jars/
        but two did not.

        One more warning for possible users picking up the 1010_server.policy file attached to this issue; if you have tracing on, you may need to resolve/pass in the property derby.drda.traceDirectory.

        Finally, this just a note, if I successfully started the server using the command identified:
        java -Djava.security.manager -Djava.security.policy=c:/policytst/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=file:///c:/jars/1010jars/ org.apache.derby.drda.NetworkServerControl start &
        I could shutdown the server with just:
        java org.apache.derby.drda.NetworkServerControl shutdown
        But when I tried to use the same policy file for the shutdown, I needed to add "connect, resolve" for the localhost:$

        {derby.security.port}

        .

        Show
        myrna Myrna van Lunteren added a comment - - edited Thanks Knut for the explanations. I probably should have grabbed the template.policy file from the source code anyway - that one works without changes if I pass the correct parameter for derby.install.url. And I did figure out what I was doing wrong, mostly mistyping the url path for the 'derby.install.url' property. For a while I missed the final '/', in a long path i.e., in the end I passed in -Dderby.install.url= file:///c:/[blahblahetc]/1010jars instead of -Dderby.install.url= file:///c:/[blahblahetc]/1010jars/ so it never found the jar files. Also, I had trouble with the number of slashes after the file url protocol identifier. One, or three worked: -Dderby.install.url= file:///c:/jars/1010jars/ -Dderby.install.url= file:/c:/jars/1010jars/ but two did not. One more warning for possible users picking up the 1010_server.policy file attached to this issue; if you have tracing on, you may need to resolve/pass in the property derby.drda.traceDirectory. Finally, this just a note, if I successfully started the server using the command identified: java -Djava.security.manager -Djava.security.policy=c:/policytst/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url= file:///c:/jars/1010jars/ org.apache.derby.drda.NetworkServerControl start & I could shutdown the server with just: java org.apache.derby.drda.NetworkServerControl shutdown But when I tried to use the same policy file for the shutdown, I needed to add "connect, resolve" for the localhost:$ {derby.security.port} .
        Hide
        chaase3 Kim Haase added a comment -

        I'm on a Unix system (Solaris) and am having trouble starting the network server too. My Derby jars ARE in /export/home/chaase/db-derby-10.10.1.1-bin/lib/.

        java -Djava.security.manager -Djava.security.policy=/home/cbhaase/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=/export/home/chaase/db-derby-10.10.1.1-bin/lib/ org.apache.derby.drda.NetworkServerControl start
        java.security.policy: error adding Entry:
        java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derby.jar
        java.security.policy: error adding Entry:
        java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derbynet.jar
        java.security.policy: error adding Entry:
        java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derbytools.jar
        java.security.policy: error adding Entry:
        java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derbyclient.jar
        Fri Jan 24 11:41:37 EST 2014 : access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write")
        java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write")
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
        at java.security.AccessController.checkPermission(AccessController.java:559)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.System.setProperty(System.java:783)
        at org.apache.derby.drda.NetworkServerControl$1.run(Unknown Source)
        at org.apache.derby.drda.NetworkServerControl$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)

        Show
        chaase3 Kim Haase added a comment - I'm on a Unix system (Solaris) and am having trouble starting the network server too. My Derby jars ARE in /export/home/chaase/db-derby-10.10.1.1-bin/lib/. java -Djava.security.manager -Djava.security.policy=/home/cbhaase/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=/export/home/chaase/db-derby-10.10.1.1-bin/lib/ org.apache.derby.drda.NetworkServerControl start java.security.policy: error adding Entry: java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derby.jar java.security.policy: error adding Entry: java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derbynet.jar java.security.policy: error adding Entry: java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derbytools.jar java.security.policy: error adding Entry: java.net.MalformedURLException: no protocol: /export/home/chaase/db-derby-10.10.1.1-bin/lib/derbyclient.jar Fri Jan 24 11:41:37 EST 2014 : access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write") java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) at java.security.AccessController.checkPermission(AccessController.java:559) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.System.setProperty(System.java:783) at org.apache.derby.drda.NetworkServerControl$1.run(Unknown Source) at org.apache.derby.drda.NetworkServerControl$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
        Hide
        rhillegas Rick Hillegas added a comment -

        Hi Kim,

        It looks to me as though you have pointed derby.install.url at a directory specification instead of an URL. What is needed is a value which begins with the "file:" literal. See the experiments which Myrna recorded in the previous comment. You may need to play around with the number of /'s which follow the file: literal.

        Show
        rhillegas Rick Hillegas added a comment - Hi Kim, It looks to me as though you have pointed derby.install.url at a directory specification instead of an URL. What is needed is a value which begins with the "file:" literal. See the experiments which Myrna recorded in the previous comment. You may need to play around with the number of /'s which follow the file: literal.
        Hide
        chaase3 Kim Haase added a comment -

        Oh silly me. One / and it started right up. Thanks!

        java -Djava.security.manager -Djava.security.policy=./1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=file:/export/home/chaase/db-derby-10.10.1.1-bin/lib/ org.apache.derby.drda.NetworkServerControl start
        Fri Jan 24 12:12:50 EST 2014 : Apache Derby Network Server - 10.10.1.1 - (1458268) started and ready to accept connections on port 1527

        Show
        chaase3 Kim Haase added a comment - Oh silly me. One / and it started right up. Thanks! java -Djava.security.manager -Djava.security.policy=./1010_server.policy -Dderby.security.port=1527 -Dderby.install.url= file:/export/home/chaase/db-derby-10.10.1.1-bin/lib/ org.apache.derby.drda.NetworkServerControl start Fri Jan 24 12:12:50 EST 2014 : Apache Derby Network Server - 10.10.1.1 - (1458268) started and ready to accept connections on port 1527
        Hide
        jamdiazdiaz jose diaz added a comment -

        I am in mac os x, using NB 7.4, glassfish 4, and get it error

        java -Djava.security.manager -Djava.security.policy=/Users/josediaz/Downloads/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=file://Applications/NetBeans/glassfish-4.0/javadb/lib/ org.apache.derby.drda.NetworkServerControl start
        Error: Could not find or load main class org.apache.derby.drda.NetworkServerControl

        Show
        jamdiazdiaz jose diaz added a comment - I am in mac os x, using NB 7.4, glassfish 4, and get it error java -Djava.security.manager -Djava.security.policy=/Users/josediaz/Downloads/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url= file://Applications/NetBeans/glassfish-4.0/javadb/lib/ org.apache.derby.drda.NetworkServerControl start Error: Could not find or load main class org.apache.derby.drda.NetworkServerControl
        Hide
        rhillegas Rick Hillegas added a comment -

        Hi Jose,

        That's the error you get when you try to boot a nonexistent class. It looks like the JVM can't find the derby jar files on your classpath. Try a simpler boot command without the security settings:

        java org.apache.derby.drda.NetworkServerControl start

        Hope this helps,
        -Rick

        Show
        rhillegas Rick Hillegas added a comment - Hi Jose, That's the error you get when you try to boot a nonexistent class. It looks like the JVM can't find the derby jar files on your classpath. Try a simpler boot command without the security settings: java org.apache.derby.drda.NetworkServerControl start Hope this helps, -Rick
        Hide
        danielstocker Daniel Stocker added a comment -

        Environment:
        OS: Windows 7 Pro SP1
        JAVA: java version "1.7.0_51", Java(TM) SE Runtime Environment (build 1.7.0_51-b13),Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
        DERBY: 10.10.1.1 (April 15, 2013 / SVN 1458268)

        Hi, I'm experiencing the issue described here:
        C:\derby\db-derby-10.10.1.1-bin\bin>startNetworkServer
        Mon Feb 24 13:06:16 NZDT 2014 : Security manager installed using the Basic server security policy.
        Mon Feb 24 13:06:19 NZDT 2014 : access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
        <snip>

        I've tried working around the issue by using the methods described, but get the same issue as others previously described:
        C:\derby\db-derby-10.10.1.1-bin\bin>java -Djava.security.manager -Djava.security.policy=c:/derby/db-derby-10.10.1.1-bin/bin/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=file:///c:/derby/db-derby-10.10.1.1-bin org.apache.derby.drda.NetworkServerControl start
        Mon Feb 24 13:10:39 NZDT 2014 : access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write")
        java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write")
        <snip>

        I tried both the earliest (17/Jan/14 18:05) and latest policy file (22/Jan/14 14:24).
        I also tried 1, 2 and 3 slashes after file: under derby.install.url parameter.
        I also tried including and excluding the trailing slash at the end of derby.install.url parameter.
        I also tried: java -Djava.security.manager -Djava.security.policy=c:/derby/db-derby-10.10.1.1-bin/bin/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url=file:///c:/derby/db-derby-10.10.1.1-bin -jar derbyrun.jar server start
        However I get the same error for all variations and am unable to get the network server running.
        I notice there are a couple of other variables inside the policy file (derby.system.home and derby.drda.traceDirectory), do I have to provide parameters for those also?
        As this is a local dev environment, perhaps the solution is to install an old version of Java SDK? In this case, which would be suitable?
        Any help would be very much appreciated

        Show
        danielstocker Daniel Stocker added a comment - Environment: OS: Windows 7 Pro SP1 JAVA: java version "1.7.0_51", Java(TM) SE Runtime Environment (build 1.7.0_51-b13),Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) DERBY: 10.10.1.1 (April 15, 2013 / SVN 1458268) Hi, I'm experiencing the issue described here: C:\derby\db-derby-10.10.1.1-bin\bin>startNetworkServer Mon Feb 24 13:06:16 NZDT 2014 : Security manager installed using the Basic server security policy. Mon Feb 24 13:06:19 NZDT 2014 : access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve") <snip> I've tried working around the issue by using the methods described, but get the same issue as others previously described: C:\derby\db-derby-10.10.1.1-bin\bin>java -Djava.security.manager -Djava.security.policy=c:/derby/db-derby-10.10.1.1-bin/bin/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url= file:///c:/derby/db-derby-10.10.1.1-bin org.apache.derby.drda.NetworkServerControl start Mon Feb 24 13:10:39 NZDT 2014 : access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write") java.security.AccessControlException: access denied ("java.util.PropertyPermission" "derby.__serverStartedFromCmdLine" "write") <snip> I tried both the earliest (17/Jan/14 18:05) and latest policy file (22/Jan/14 14:24). I also tried 1, 2 and 3 slashes after file: under derby.install.url parameter. I also tried including and excluding the trailing slash at the end of derby.install.url parameter. I also tried: java -Djava.security.manager -Djava.security.policy=c:/derby/db-derby-10.10.1.1-bin/bin/1010_server.policy -Dderby.security.port=1527 -Dderby.install.url= file:///c:/derby/db-derby-10.10.1.1-bin -jar derbyrun.jar server start However I get the same error for all variations and am unable to get the network server running. I notice there are a couple of other variables inside the policy file (derby.system.home and derby.drda.traceDirectory), do I have to provide parameters for those also? As this is a local dev environment, perhaps the solution is to install an old version of Java SDK? In this case, which would be suitable? Any help would be very much appreciated
        Hide
        rhillegas Rick Hillegas added a comment -

        Hi Daniel,

        The url which worked for Kim pointed at a directory which contains the Derby jars: file:///c:/jars/1010jars/ . It looks to me as though your url is pointing at the directory above the jar directory. Try...

        file:///c:/derby/db-derby-10.10.1.1-bin/lib/

        ...instead of

        file:///c:/derby/db-derby-10.10.1.1-bin

        The derby.system.home variable will be set by the Derby network server before it installs a security manager. The other variable, derby.drda.traceDirectory is not automatically set; but you only need to set it if you are tracing a network protocol handshake.

        If you need to downgrade your java version, 7u45 should work.

        If this is just a problem you're experiencing in development, you can turn off the security manager by setting the -noSecurityManager flag as described here: http://db.apache.org/derby/docs/10.10/adminguide/tadminnetservopen.html

        Hope this helps,
        -Rick

        Show
        rhillegas Rick Hillegas added a comment - Hi Daniel, The url which worked for Kim pointed at a directory which contains the Derby jars: file:///c:/jars/1010jars/ . It looks to me as though your url is pointing at the directory above the jar directory. Try... file:///c:/derby/db-derby-10.10.1.1-bin/lib/ ...instead of file:///c:/derby/db-derby-10.10.1.1-bin The derby.system.home variable will be set by the Derby network server before it installs a security manager. The other variable, derby.drda.traceDirectory is not automatically set; but you only need to set it if you are tracing a network protocol handshake. If you need to downgrade your java version, 7u45 should work. If this is just a problem you're experiencing in development, you can turn off the security manager by setting the -noSecurityManager flag as described here: http://db.apache.org/derby/docs/10.10/adminguide/tadminnetservopen.html Hope this helps, -Rick
        Hide
        danielstocker Daniel Stocker added a comment -

        Legend! Cheers Rick, much appreciated, all sorted, easy as that

        Show
        danielstocker Daniel Stocker added a comment - Legend! Cheers Rick, much appreciated, all sorted, easy as that
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1595085 from Myrna van Lunteren in branch 'code/branches/10.4'
        [ https://svn.apache.org/r1595085 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        merge of revision 1556909 from 10.5

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1595085 from Myrna van Lunteren in branch 'code/branches/10.4' [ https://svn.apache.org/r1595085 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy merge of revision 1556909 from 10.5
        Hide
        myrna Myrna van Lunteren added a comment -

        I'm reopening for backport to 10.4 and 10.3 after all.

        Show
        myrna Myrna van Lunteren added a comment - I'm reopening for backport to 10.4 and 10.3 after all.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1595710 from Myrna van Lunteren in branch 'code/branches/10.3'
        [ https://svn.apache.org/r1595710 ]

        DERBY-6438; Explicitly grant SocketPermission "listen" in default server policy
        merge of revision 1595085 from 10.4

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1595710 from Myrna van Lunteren in branch 'code/branches/10.3' [ https://svn.apache.org/r1595710 ] DERBY-6438 ; Explicitly grant SocketPermission "listen" in default server policy merge of revision 1595085 from 10.4
        Hide
        myrna Myrna van Lunteren added a comment -

        Resolving again.
        Note that this permission is also needed with the latest ibm 1.5 fix packs - so even for 10.1 and 10.2.
        I have frozen my saved test environments for 10.1 and 10.2 at ibm1.5.SR16 fp3, where the listen permission was not yet needed.

        Show
        myrna Myrna van Lunteren added a comment - Resolving again. Note that this permission is also needed with the latest ibm 1.5 fix packs - so even for 10.1 and 10.2. I have frozen my saved test environments for 10.1 and 10.2 at ibm1.5.SR16 fp3, where the listen permission was not yet needed.
        Hide
        myrna Myrna van Lunteren added a comment -

        bulk change to close all issues resolved but not closed and not changed since June 1, 2014.

        Show
        myrna Myrna van Lunteren added a comment - bulk change to close all issues resolved but not closed and not changed since June 1, 2014.

          People

          • Assignee:
            knutanders Knut Anders Hatlen
            Reporter:
            knutanders Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development