Derby
  1. Derby
  2. DERBY-811

Creating trace files in derbytclient fails when running with a SecurityManager

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.1.2.1, 10.2.1.6
    • Fix Version/s: 10.3.1.4
    • Component/s: Network Client
    • Labels:
      None
    • Bug behavior facts:
      Security

      Description

      Can be seen by running the test jdbcapi/checkDriver.java in the DerbyNetClient framework.

      Another bug in the code is in ClientBaseDataSource.computePrintWriter where the file separator is hard coded as "/".

      java.security.AccessControlException: access denied (java.io.FilePermission C:_work\svn_clean2\trunk\systest\out2\DerbyNetClient\checkDriver\trace.out write)
      at java.security.AccessControlContext.checkPermission(AccessControlContext.java:292)
      at java.security.AccessController.checkPermission(AccessController.java:476)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:538)
      at java.lang.SecurityManager.checkWrite(SecurityManager.java:968)
      at java.io.FileOutputStream.<init>(FileOutputStream.java:191)
      at java.io.FileOutputStream.<init>(FileOutputStream.java:124)
      at org.apache.derby.client.am.LogWriter.getPrintWriter(LogWriter.java:1190)
      at org.apache.derby.jdbc.ClientBaseDataSource.computePrintWriter(ClientBaseDataSource.java:587)
      at org.apache.derby.jdbc.ClientBaseDataSource.computeDncLogWriter(ClientBaseDataSource.java:528)
      at org.apache.derby.jdbc.ClientBaseDataSource.computeDncLogWriterForNewConnection(ClientBaseDataSource.java:512)
      at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:116)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDriver.testConnect(checkDriver.java:397)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDriver.testClientAttributes(checkDriver.java:177)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDriver.main(checkDriver.java:133)

        Activity

        Hide
        Mamta A. Satoor added a comment -

        I am looking into the derby dev list to see how to run an old harness test with java security but what I found so far does not seem to work for me. Following is what I am trying
        java -Djava.security.manager -Djava.security.policy=file:/c:/p4clients/maintest3/classes/derby_tests.policy -DderbyTesting.codeclasses=file:/c:/p4clients/maintest3/classes/. -DderbyTesting.codedir=file:/c:/p4clients/maintest3/classes/ -DderbyTesting.codejar=file://unused/ org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDriver.java

        I get following error
        Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission C:\p4clients\maintest3\classes write)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
        at java.security.AccessController.checkPermission(AccessController.java:401)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
        at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
        at java.io.File.mkdir(File.java:1097)
        at org.apache.derbyTesting.functionTests.harness.RunTest.setDirectories(RunTest.java:636)
        at org.apache.derbyTesting.functionTests.harness.RunTest.main(RunTest.java:266)

        Can someone give me a pointer as to how a non-junit test is run with security manager?

        Show
        Mamta A. Satoor added a comment - I am looking into the derby dev list to see how to run an old harness test with java security but what I found so far does not seem to work for me. Following is what I am trying java -Djava.security.manager -Djava.security.policy= file:/c:/p4clients/maintest3/classes/derby_tests.policy -DderbyTesting.codeclasses= file:/c:/p4clients/maintest3/classes/ . -DderbyTesting.codedir= file:/c:/p4clients/maintest3/classes/ -DderbyTesting.codejar= file://unused/ org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDriver.java I get following error Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission C:\p4clients\maintest3\classes write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) at java.io.File.mkdir(File.java:1097) at org.apache.derbyTesting.functionTests.harness.RunTest.setDirectories(RunTest.java:636) at org.apache.derbyTesting.functionTests.harness.RunTest.main(RunTest.java:266) Can someone give me a pointer as to how a non-junit test is run with security manager?
        Hide
        Mamta A. Satoor added a comment -

        I added -Dderby.system.home to my command above and that moved me beuond the write FilePermission. Instead, now I get FilePermission <<ALL FILES>> execute) exception.

        Exact command is as follows
        $ java -Djava.security.manager= -Djava.security.policy=file:/c:/p4clients/maintest3/classes/derby_tests.policy -Dframework=DerbyNetClient -DderbyTesting.codeclasses=file:/c:/p4clients/maintest3/classes/. -DderbyTesting.codedir=file:/c:/p4clients/maintest3/classes/ -Dderby.system.home=file:/c:/p4clients/maintest3/classes/ -DderbyTesting.codejar=file://unused/ org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDriver.java

        And the error message returned is as follows
        – listing properties –
        derby.user.testuser=testpass
        derby.authentication.provider=BUILTIN
        derby.infolog.append=true
        derby.debug.true=AuthenticationTrace
        derby.database.users.testpropdb=testuser,APP
        derby.user.APP=xxxx
        Process exception: java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)

            • Start: checkDriver jdk1.4.2_07 DerbyNetClient 2007-02-08 12:10:59 ***
              Initialize for framework: DerbyNetClient
              java -Duser.language=en -Duser.country=US -Dderby.system.home=C:\p4clients\maintest3\classes\DerbyNetClient\checkDriver -Djava.security.manager -Djava.security.policy=C:\p4clients\maintest3\classes\derby_tests.policy -DderbyTesting.codedir=C:\p4clients\maintest3\classes -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost org.apache.derby.drda.NetworkServerControl start
              Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)
              at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
              at java.security.AccessController.checkPermission(AccessController.java:401)
              at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
              at java.lang.SecurityManager.checkExec(SecurityManager.java:774)
              at java.lang.Runtime.exec(Runtime.java:563)
              at java.lang.Runtime.exec(Runtime.java:491)
              at java.lang.Runtime.exec(Runtime.java:457)
              at org.apache.derbyTesting.functionTests.harness.NetServer.start(NetServer.java:192)
              at org.apache.derbyTesting.functionTests.harness.RunTest.main(RunTest.java:351)
              $
        Show
        Mamta A. Satoor added a comment - I added -Dderby.system.home to my command above and that moved me beuond the write FilePermission. Instead, now I get FilePermission <<ALL FILES>> execute) exception. Exact command is as follows $ java -Djava.security.manager= -Djava.security.policy= file:/c:/p4clients/maintest3/classes/derby_tests.policy -Dframework=DerbyNetClient -DderbyTesting.codeclasses= file:/c:/p4clients/maintest3/classes/ . -DderbyTesting.codedir= file:/c:/p4clients/maintest3/classes/ -Dderby.system.home= file:/c:/p4clients/maintest3/classes/ -DderbyTesting.codejar= file://unused/ org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDriver.java And the error message returned is as follows – listing properties – derby.user.testuser=testpass derby.authentication.provider=BUILTIN derby.infolog.append=true derby.debug.true=AuthenticationTrace derby.database.users.testpropdb=testuser,APP derby.user.APP=xxxx Process exception: java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute) Start: checkDriver jdk1.4.2_07 DerbyNetClient 2007-02-08 12:10:59 *** Initialize for framework: DerbyNetClient java -Duser.language=en -Duser.country=US -Dderby.system.home=C:\p4clients\maintest3\classes\DerbyNetClient\checkDriver -Djava.security.manager -Djava.security.policy=C:\p4clients\maintest3\classes\derby_tests.policy -DderbyTesting.codedir=C:\p4clients\maintest3\classes -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost org.apache.derby.drda.NetworkServerControl start Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkExec(SecurityManager.java:774) at java.lang.Runtime.exec(Runtime.java:563) at java.lang.Runtime.exec(Runtime.java:491) at java.lang.Runtime.exec(Runtime.java:457) at org.apache.derbyTesting.functionTests.harness.NetServer.start(NetServer.java:192) at org.apache.derbyTesting.functionTests.harness.RunTest.main(RunTest.java:351) $
        Hide
        Andrew McIntyre added a comment -

        The old test harness runs with security manager enabled by default, unless the test specifies not to run with the security manager in its _app.properties.

        checkDriver currently has this in its _app.properties:

        #exclude with SecurityManager DERBY-811
        noSecurityManager=true

        remove these lines and rebuild to run the test with the security manager in the old harness.

        Show
        Andrew McIntyre added a comment - The old test harness runs with security manager enabled by default, unless the test specifies not to run with the security manager in its _app.properties. checkDriver currently has this in its _app.properties: #exclude with SecurityManager DERBY-811 noSecurityManager=true remove these lines and rebuild to run the test with the security manager in the old harness.
        Hide
        Mamta A. Satoor added a comment -

        Thanks, Andrew. I was able to run the test with SecurityManager after removing the noSecurityManager=true from checkDriver_app.properties.

        I ran checkDriver test with the Derby jar files under DerbyNetClient framework after the fix for DERBY-1275 was committed and there was no security related exceptions. I have attached the patch DERBY811_RunCheckDriverWithSecurityManager_diff_v01.txt which removes noSecurityManager=true from checkDriver_app.properties. If there are no objections to this change, then I will commit it sometime tomorrow.

        As for the ClientBaseDataSource.computePrintWriter using hard coded "/" rather than File.separator, I will make that change next and post another patch after running some basic tests.

        Show
        Mamta A. Satoor added a comment - Thanks, Andrew. I was able to run the test with SecurityManager after removing the noSecurityManager=true from checkDriver_app.properties. I ran checkDriver test with the Derby jar files under DerbyNetClient framework after the fix for DERBY-1275 was committed and there was no security related exceptions. I have attached the patch DERBY811_RunCheckDriverWithSecurityManager_diff_v01.txt which removes noSecurityManager=true from checkDriver_app.properties. If there are no objections to this change, then I will commit it sometime tomorrow. As for the ClientBaseDataSource.computePrintWriter using hard coded "/" rather than File.separator, I will make that change next and post another patch after running some basic tests.
        Hide
        Mamta A. Satoor added a comment -

        Committed DERBY811_RunCheckDriverWithSecurityManager_diff_v01.txt with following comment (revision number 505317)
        DERBY-811 Enabling SecurityManager for checkDriver test. This test was running into problems when run with Derby jar files in DerbyNetClient framework with SecurityManager. This is because required permissions were not granted to the jar in the policy file. Fix for DERBY-1275 took care of those permissions and hence checkDriver test can now start running with SecurityManager.

        Show
        Mamta A. Satoor added a comment - Committed DERBY811_RunCheckDriverWithSecurityManager_diff_v01.txt with following comment (revision number 505317) DERBY-811 Enabling SecurityManager for checkDriver test. This test was running into problems when run with Derby jar files in DerbyNetClient framework with SecurityManager. This is because required permissions were not granted to the jar in the policy file. Fix for DERBY-1275 took care of those permissions and hence checkDriver test can now start running with SecurityManager.
        Hide
        Daniel John Debrunner added a comment -

        Actually the code changes for DERBY-1275 really fixed this issue. Before, the opening of the file was not in a privileged block (see the initial stack trace for this issue). Thus just adding the policies would not have fixed this. Just wanted to track this down to see what issue had fixed it.

        Show
        Daniel John Debrunner added a comment - Actually the code changes for DERBY-1275 really fixed this issue. Before, the opening of the file was not in a privileged block (see the initial stack trace for this issue). Thus just adding the policies would not have fixed this. Just wanted to track this down to see what issue had fixed it.
        Hide
        Mamta A. Satoor added a comment -

        Agreed. Just the policy file changes wouldn't have been enough to fix checkDriver test failure.

        I guess what I meant to say is without the accompanying changes to policy file for jars, checkDriver would have still failed when run with jars (even with the code changes for DERBY-1275). Just like what happened with the JUnit test added as part of DERBY-1275 failed when run with jar files (DERBY-2302)

        Show
        Mamta A. Satoor added a comment - Agreed. Just the policy file changes wouldn't have been enough to fix checkDriver test failure. I guess what I meant to say is without the accompanying changes to policy file for jars, checkDriver would have still failed when run with jars (even with the code changes for DERBY-1275 ). Just like what happened with the JUnit test added as part of DERBY-1275 failed when run with jar files ( DERBY-2302 )
        Hide
        Mamta A. Satoor added a comment -

        Very simple change as part of review package DERBY811_RemoveHardcodedSlashForFileSeparator_diff_v01.txt to remove hard coded "/" and user File.separator instead.

        If no objections to the changes, then I will commit it over next couple days.

        Show
        Mamta A. Satoor added a comment - Very simple change as part of review package DERBY811_RemoveHardcodedSlashForFileSeparator_diff_v01.txt to remove hard coded "/" and user File.separator instead. If no objections to the changes, then I will commit it over next couple days.
        Hide
        Mamta A. Satoor added a comment -

        Committed DERBY811_RemoveHardcodedSlashForFileSeparator_diff_v01.txt with revision 506160

        Show
        Mamta A. Satoor added a comment - Committed DERBY811_RemoveHardcodedSlashForFileSeparator_diff_v01.txt with revision 506160
        Hide
        Mike Matrigali added a comment -

        Is this issue fixed now?

        Show
        Mike Matrigali added a comment - Is this issue fixed now?

          People

          • Assignee:
            Mamta A. Satoor
            Reporter:
            Daniel John Debrunner
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development