Derby
  1. Derby
  2. DERBY-4292

creation of FileInputStream in org.apache.derby.impl.tools.ij.Main not wrapped in privilege block which can cause problems running under SecurityManager

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.2.0, 10.5.1.1, 10.6.1.0
    • Fix Version/s: 10.5.3.0, 10.6.1.0
    • Component/s: Tools
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      High Value Fix, Newcomer, Repro attached
    • Bug behavior facts:
      Security

      Description

      org.apache.derby.impl.tools.ij.Main has this code where the call to FileInputStream is not wrapped in a privilege block:

      try {
      in1 = new FileInputStream(file);
      if (in1 != null)

      { in1 = new BufferedInputStream(in1, utilMain.BUFFEREDFILESIZE); in = langUtil.getNewInput(in1); }

      } catch (FileNotFoundException e) {
      if (Boolean.getBoolean("ij.searchClassPath"))

      { in = langUtil.getNewInput(util.getResourceAsStream(file)); }

      This can cause issues when running under SecurityManager

      1. run.out.debugall
        34 kB
        Kathey Marsden
      2. DERBY-4292-ReproTest.patch
        3 kB
        Tiago R. Espinha
      3. DERBY-4292-ReproTest.patch
        7 kB
        Tiago R. Espinha
      4. DERBY-4292-ReproTest.patch
        7 kB
        Tiago R. Espinha
      5. DERBY-4292-Fix.patch
        1 kB
        Tiago R. Espinha
      6. DERBY-4292-Fix.patch
        2 kB
        Tiago R. Espinha
      7. DERBY-4292-Fix.patch
        2 kB
        Tiago R. Espinha
      8. derby4292.zip
        5 kB
        Kathey Marsden
      9. derby4292.zip
        3 kB
        Kathey Marsden

        Activity

        Gavin made changes -
        Workflow jira [ 12466884 ] Default workflow, editable Closed status [ 12799379 ]
        Tiago R. Espinha made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Tiago R. Espinha added a comment -

        The patch has been committed and no failures were seen. Closing the issue.

        Show
        Tiago R. Espinha added a comment - The patch has been committed and no failures were seen. Closing the issue.
        Hide
        Kathey Marsden added a comment -

        I accidentally checked in some unrelated test changes to BlobClob4BlobTest with the 10.5 checkin. This caused three failures in the nightlies. Corrected this with revision 795425. Sorry for the noise.

        Show
        Kathey Marsden added a comment - I accidentally checked in some unrelated test changes to BlobClob4BlobTest with the 10.5 checkin. This caused three failures in the nightlies. Corrected this with revision 795425. Sorry for the noise.
        Kathey Marsden made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 10.5.2.1 [ 12314117 ]
        Fix Version/s 10.6.0.0 [ 12313727 ]
        Resolution Fixed [ 1 ]
        Hide
        Kathey Marsden added a comment -

        Submitted this fix to trunk and 10.5 branch
        Thanks Tiago

        Show
        Kathey Marsden added a comment - Submitted this fix to trunk and 10.5 branch Thanks Tiago
        Hide
        Tiago R. Espinha added a comment -

        I've merged this patch into 10.5 with the following command:
        svn merge -r 794111:794112 https://svn.apache.org/repos/asf/db/derby/code/trunk

        I also ran suites.All for 10.5 after the merge and I got no failures.

        Show
        Tiago R. Espinha added a comment - I've merged this patch into 10.5 with the following command: svn merge -r 794111:794112 https://svn.apache.org/repos/asf/db/derby/code/trunk I also ran suites.All for 10.5 after the merge and I got no failures.
        Hide
        Kathey Marsden added a comment -

        Committed revision 794112. I will leave this open because I think it would be good to backport to 10.5 although it probably won't make the Release candidate.

        Show
        Kathey Marsden added a comment - Committed revision 794112. I will leave this open because I think it would be good to backport to 10.5 although it probably won't make the Release candidate.
        Hide
        Kathey Marsden added a comment -

        I think it is ok to check this patch in as is as soon as we get the results of your regression tests.

        Regarding the test for the non-existent file, I am not quite sure what you mean regarding the SupportFilesSetup as that wouldn't be used, we would just call ij and specify a file that does not exist. I do however see how such a test would be problematic as long as we have the problem of the error just going to System.out. I guess that it would make the most sense to add that test when that issue is fixed.

        I think we need 2 new bugs after this one goes in, both minor or even trivial: One for the ij exit code when the file is not found and another for the NullPointerException if the resource is not found with ij.searchClassPath. Mark both newcomer.

        Show
        Kathey Marsden added a comment - I think it is ok to check this patch in as is as soon as we get the results of your regression tests. Regarding the test for the non-existent file, I am not quite sure what you mean regarding the SupportFilesSetup as that wouldn't be used, we would just call ij and specify a file that does not exist. I do however see how such a test would be problematic as long as we have the problem of the error just going to System.out. I guess that it would make the most sense to add that test when that issue is fixed. I think we need 2 new bugs after this one goes in, both minor or even trivial: One for the ij exit code when the file is not found and another for the NullPointerException if the resource is not found with ij.searchClassPath. Mark both newcomer.
        Tiago R. Espinha made changes -
        Attachment DERBY-4292-ReproTest.patch [ 12412994 ]
        Hide
        Tiago R. Espinha added a comment -

        I'm attaching the latest patch to this issue.

        Kathey said:
        > "...and add a test if the file does not exist..."
        Is this really necessary? If the file does not exist in the Derby code tree, the SupportFilesSetup will blow up on its own, and if it does exist there, then it is safe to say that it will exist in the extinout folder.

        If anything, I think we can later on change that ij behavior and make it throw an exception rather than an error message, so that the test fails when the file does not exist.

        What I'm thinking is that by putting such check on a test, we sort of are masking the problem with ij exiting with status 0 even when the file does not exist. If you think we should have that check anyway, I can easily do it with a new File().exists().

        For this patch (just the Repro test) I removed the SecurityManager decorator and added the header to the sql file. The fix remains the same.

        I'll be running regressions today.

        Show
        Tiago R. Espinha added a comment - I'm attaching the latest patch to this issue. Kathey said: > "...and add a test if the file does not exist..." Is this really necessary? If the file does not exist in the Derby code tree, the SupportFilesSetup will blow up on its own, and if it does exist there, then it is safe to say that it will exist in the extinout folder. If anything, I think we can later on change that ij behavior and make it throw an exception rather than an error message, so that the test fails when the file does not exist. What I'm thinking is that by putting such check on a test, we sort of are masking the problem with ij exiting with status 0 even when the file does not exist. If you think we should have that check anyway, I can easily do it with a new File().exists(). For this patch (just the Repro test) I removed the SecurityManager decorator and added the header to the sql file. The fix remains the same. I'll be running regressions today.
        Kathey Marsden made changes -
        Attachment derby4292.zip [ 12412959 ]
        Hide
        Kathey Marsden added a comment -

        The original repro derby4292.zip had some problems with the script and the permissions in the policy file. Updating with the corrected version which fails without the fix and passes with it just for the record. Tiago's test seems to handle this all correctly.

        Show
        Kathey Marsden added a comment - The original repro derby4292.zip had some problems with the script and the permissions in the policy file. Updating with the corrected version which fails without the fix and passes with it just for the record. Tiago's test seems to handle this all correctly.
        Hide
        Kathey Marsden added a comment -

        Well it seems with your new patch we don't have a problem running under security manger when we hit the Boolean.getBoolean() call so I guess it is ok. The javadoc also indicates that no checks are done. I don't know why.
        http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String)

        I verified that ij.searchClassPath is working ok by running:

        java -Dderby.system.home=C:/kmarsden/repro/derby-4292 -Dij.searchClassPath=true -Djava.security.manager -DderbyTesting.codejar=file:/C:/svn4/trunk/jars/sane/ -Djava.security.policy=C:/kmarsden/repro/derby-4292/derby_tests.policy org.apache.derby.tools.ij /org/apache/derbyTesting/functionTests/tests/tools/IjSecurityManagerTest.sql

        If I specify a resource that doesn't exist with ij.searchClassPath I get a pre-existing NPE:
        Exception in thread "main" java.lang.NullPointerException
        at java.io.Reader.<init>(Reader.java:61)
        at java.io.InputStreamReader.<init>(InputStreamReader.java:55)
        at org.apache.derby.iapi.tools.i18n.LocalizedInput.<init>(LocalizedInput.java:32)
        at org.apache.derby.iapi.tools.i18n.LocalizedResource.getNewInput(LocalizedResource.java:241)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:131)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
        at org.apache.derby.tools.ij.main(ij.java:59)

        I don't know if that needs a bug since we don't seem to document this property.

        As an aside, I don't like the way ij just prints the error to the output and returns instead of throwing an exception. This means it won't exit with an error code if it can't find the file.
        [C:/kmarsden/repro/derby-4292] java org.apache.derby.tools.ij notthere.sql
        IJ ERROR: file not found: notthere.sql
        [C:/kmarsden/repro/derby-4292] echo $?
        0

        That too is preexisting.

        So with regard to your patch I think the fix looks fine. For the test patch you should remove the SecurityManager setup, and add a test if the file does not exist, and add the header to the sql file.

        Show
        Kathey Marsden added a comment - Well it seems with your new patch we don't have a problem running under security manger when we hit the Boolean.getBoolean() call so I guess it is ok. The javadoc also indicates that no checks are done. I don't know why. http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String ) I verified that ij.searchClassPath is working ok by running: java -Dderby.system.home=C:/kmarsden/repro/derby-4292 -Dij.searchClassPath=true -Djava.security.manager -DderbyTesting.codejar= file:/C:/svn4/trunk/jars/sane/ -Djava.security.policy=C:/kmarsden/repro/derby-4292/derby_tests.policy org.apache.derby.tools.ij /org/apache/derbyTesting/functionTests/tests/tools/IjSecurityManagerTest.sql If I specify a resource that doesn't exist with ij.searchClassPath I get a pre-existing NPE: Exception in thread "main" java.lang.NullPointerException at java.io.Reader.<init>(Reader.java:61) at java.io.InputStreamReader.<init>(InputStreamReader.java:55) at org.apache.derby.iapi.tools.i18n.LocalizedInput.<init>(LocalizedInput.java:32) at org.apache.derby.iapi.tools.i18n.LocalizedResource.getNewInput(LocalizedResource.java:241) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:131) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) I don't know if that needs a bug since we don't seem to document this property. As an aside, I don't like the way ij just prints the error to the output and returns instead of throwing an exception. This means it won't exit with an error code if it can't find the file. [C:/kmarsden/repro/derby-4292] java org.apache.derby.tools.ij notthere.sql IJ ERROR: file not found: notthere.sql [C:/kmarsden/repro/derby-4292] echo $? 0 That too is preexisting. So with regard to your patch I think the fix looks fine. For the test patch you should remove the SecurityManager setup, and add a test if the file does not exist, and add the header to the sql file.
        Hide
        Kathey Marsden added a comment -

        The AccessControlException with the fix and my repro was user error. I had an extra slash in my derbyTesting.codejar setting. The command line in run.sh should have been:
        java -Dderby.system.home=C:/kmarsden/repro/derby-4292 -Djava.security.manager -DderbyTesting.codejar=file:/C:/svn4/trunk/jars/sane/ -Djava.security.policy=C:/kmarsden/repro/derby-4292/derby_tests.policy org.apache.derby.tools.ij repro.sql

        With that change it works fine.

        Show
        Kathey Marsden added a comment - The AccessControlException with the fix and my repro was user error. I had an extra slash in my derbyTesting.codejar setting. The command line in run.sh should have been: java -Dderby.system.home=C:/kmarsden/repro/derby-4292 -Djava.security.manager -DderbyTesting.codejar= file:/C:/svn4/trunk/jars/sane/ -Djava.security.policy=C:/kmarsden/repro/derby-4292/derby_tests.policy org.apache.derby.tools.ij repro.sql With that change it works fine.
        Tiago R. Espinha made changes -
        Attachment DERBY-4292-Fix.patch [ 12412934 ]
        Hide
        Tiago R. Espinha added a comment -

        This patch fixes the regression issue when the file does not exist.

        Show
        Tiago R. Espinha added a comment - This patch fixes the regression issue when the file does not exist.
        Kathey Marsden made changes -
        Attachment run.out.debugall [ 12412916 ]
        Hide
        Kathey Marsden added a comment -

        Hi Tiago I am still looking at the patch but noticed a few things that I wanted to mention.
        1) The repro that I posted originally doesn't seem to work with the patch. I can't quite figure out why. derby_tests.policy has this permission which should allow us to read repro.sql:

        // Read all files under $

        {user.dir}
        permission java.io.FilePermission "${user.dir}

        $

        {/}

        -", "read";

        but yet I get:
        Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission repro
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
        at java.io.FileInputStream.<init>(FileInputStream.java:100)
        at java.io.FileInputStream.<init>(FileInputStream.java:66)
        at org.apache.derby.impl.tools.ij.Main$1.run(Main.java:124)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:120)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
        at org.apache.derby.tools.ij.main(ij.java:59)
        I am attaching run.out.debugall which has the output when -Djava.security.debug=all is set. It seems to read the permission fine but not use it later. I must be missing something simple.
        This is with:
        java version "1.6.0_01"
        Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
        Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode)

        2) The patch introduces a regression NullPointerException if the file is not found:
        Exception in thread "main" java.lang.NullPointerException
        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:207)
        at org.apache.derby.impl.tools.ij.Main.go(Main.java:235)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:190)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
        at org.apache.derby.tools.ij.main(ij.java:59)
        vs
        IJ ERROR: file not found: test.sql
        before the patch.

        3) I noticed there is also a Boolean.getBoolean("ij.searchClassPath") in the same area of code which I think is going to need a privilege block too. We can handle that with this issue or create another one.
        4) In the test I think you can get rid of
        test = new SecurityManagerSetup(test, policyName);
        all together. That is the policy file that will get picked up by default.

        5) Even our little tiny sql file needs a header. See other sql files for an example.

        Show
        Kathey Marsden added a comment - Hi Tiago I am still looking at the patch but noticed a few things that I wanted to mention. 1) The repro that I posted originally doesn't seem to work with the patch. I can't quite figure out why. derby_tests.policy has this permission which should allow us to read repro.sql: // Read all files under $ {user.dir} permission java.io.FilePermission "${user.dir} $ {/} -", "read"; but yet I get: Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission repro at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.FileInputStream.<init>(FileInputStream.java:100) at java.io.FileInputStream.<init>(FileInputStream.java:66) at org.apache.derby.impl.tools.ij.Main$1.run(Main.java:124) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:120) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) I am attaching run.out.debugall which has the output when -Djava.security.debug=all is set. It seems to read the permission fine but not use it later. I must be missing something simple. This is with: java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode) 2) The patch introduces a regression NullPointerException if the file is not found: Exception in thread "main" java.lang.NullPointerException at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:207) at org.apache.derby.impl.tools.ij.Main.go(Main.java:235) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:190) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) vs IJ ERROR: file not found: test.sql before the patch. 3) I noticed there is also a Boolean.getBoolean("ij.searchClassPath") in the same area of code which I think is going to need a privilege block too. We can handle that with this issue or create another one. 4) In the test I think you can get rid of test = new SecurityManagerSetup(test, policyName); all together. That is the policy file that will get picked up by default. 5) Even our little tiny sql file needs a header. See other sql files for an example.
        Tiago R. Espinha made changes -
        Attachment DERBY-4292-Fix.patch [ 12412895 ]
        Attachment DERBY-4292-ReproTest.patch [ 12412896 ]
        Hide
        Tiago R. Espinha added a comment -

        Attaching a new fix and repro test that takes Kathey's comments into consideration.

        • Add Apache licence header to new files - CHECK
        • For your privilege block in Main.java, use PrivilegedExceptionAction instead of PrivilegedAction so you can throw the original exception instead of creating a new one if the file is not found. See PrivilegedFileOpsForTests.getFileOutputStream() for an example. - CHECK
        • In the test if it is using the standard policy file, why do we need to copy it to a special one for this test? - CHECK
        • The test should be added to a suite. - CHECK
        • I would keep the same name when copying IjSecurityManagerTest.sql - CHECK
        • Regarding the output I am not sure the best way to handle it. There is System.setOut that could be set and restored, but that seems extreme. I will think about it. - CHECK

        Please note that both patches have to be committed. One is the repro test that makes the bug show, the other is the fix to patch it.

        Show
        Tiago R. Espinha added a comment - Attaching a new fix and repro test that takes Kathey's comments into consideration. Add Apache licence header to new files - CHECK For your privilege block in Main.java, use PrivilegedExceptionAction instead of PrivilegedAction so you can throw the original exception instead of creating a new one if the file is not found. See PrivilegedFileOpsForTests.getFileOutputStream() for an example. - CHECK In the test if it is using the standard policy file, why do we need to copy it to a special one for this test? - CHECK The test should be added to a suite. - CHECK I would keep the same name when copying IjSecurityManagerTest.sql - CHECK Regarding the output I am not sure the best way to handle it. There is System.setOut that could be set and restored, but that seems extreme. I will think about it. - CHECK Please note that both patches have to be committed. One is the repro test that makes the bug show, the other is the fix to patch it.
        Hide
        Tiago R. Espinha added a comment -

        Thank you for your comments Kathey.

        • You are right on the policy file bit. I had that code from another test and I was going under the assumption that it was ultimately necessary to copy the policy file; that isn't the case so I'll change that.
        • I'll create a new patch with all your other comments added.

        On the output part, after having discussed this with Kathey on IRC, we landed on two options:
        a) Run ij with execJavaCmd - this option implies having the policy file for this process defined through system properties. It also implies copying over a policy file.

        b) Run ij as it is ("programatically") and before it is ran, do:
        System.setOut(new PrintStream(new NullOutputStream));

        This effectively mutes any output and after the fixture is ran, the plan is to restore it to the original System.out in a finally block.

        At this point, this is the method we agreed would be less bad, so I'm going forward with this one on the patch.

        Show
        Tiago R. Espinha added a comment - Thank you for your comments Kathey. You are right on the policy file bit. I had that code from another test and I was going under the assumption that it was ultimately necessary to copy the policy file; that isn't the case so I'll change that. I'll create a new patch with all your other comments added. On the output part, after having discussed this with Kathey on IRC, we landed on two options: a) Run ij with execJavaCmd - this option implies having the policy file for this process defined through system properties. It also implies copying over a policy file. b) Run ij as it is ("programatically") and before it is ran, do: System.setOut(new PrintStream(new NullOutputStream)); This effectively mutes any output and after the fixture is ran, the plan is to restore it to the original System.out in a finally block. At this point, this is the method we agreed would be less bad, so I'm going forward with this one on the patch.
        Hide
        Kathey Marsden added a comment -

        Thanks Tiago for the patch. Here are some comments.

        • Add Apache licence header to new files
        • For your privilege block in Main.java, use PrivilegedExceptionAction instead of PrivilegedAction so you can throw the original exception instead of creating a new one if the file is not found. See PrivilegedFileOpsForTests.getFileOutputStream() for an example.
        • In the test if it is using the standard policy file, why do we need to copy it to a special one for this test?
        • The test should be added to a suite.
        • I would keep the same name when copying IjSecurityManagerTest.sql
        • Regarding the output I am not sure the best way to handle it. There is System.setOut that could be set and restored, but that seems extreme. I will think about it.
        Show
        Kathey Marsden added a comment - Thanks Tiago for the patch. Here are some comments. Add Apache licence header to new files For your privilege block in Main.java, use PrivilegedExceptionAction instead of PrivilegedAction so you can throw the original exception instead of creating a new one if the file is not found. See PrivilegedFileOpsForTests.getFileOutputStream() for an example. In the test if it is using the standard policy file, why do we need to copy it to a special one for this test? The test should be added to a suite. I would keep the same name when copying IjSecurityManagerTest.sql Regarding the output I am not sure the best way to handle it. There is System.setOut that could be set and restored, but that seems extreme. I will think about it.
        Tiago R. Espinha made changes -
        Attachment DERBY-4292-Fix.patch [ 12412547 ]
        Attachment DERBY-4292-ReproTest.patch [ 12412548 ]
        Hide
        Tiago R. Espinha added a comment -

        I'm submitting two files to this issue. The ReproTest contains a test that reproduces the flaw. If this patch is applied and the test is ran without the fix, it should fail. This acknowledges the existence of the flaw.

        The fix simply wraps the 'offending' code in a privilege block, making the repro test pass.

        There's one issue with the test: since I am invoking ij manually from within the fixture, the output gets printed to the console. Does anyone have any suggestions to mute this output? We don't really need to see the output since we can handle the exception instead, in case it throws one.

        It needs also to be noted that the policy file being used is the already existent util/derby_tests.policy since it serves the purpose of the test. However, a new file (tools/IjSecurityManagerTest.sql) is added that is used to reproduce the failure.

        Show
        Tiago R. Espinha added a comment - I'm submitting two files to this issue. The ReproTest contains a test that reproduces the flaw. If this patch is applied and the test is ran without the fix, it should fail. This acknowledges the existence of the flaw. The fix simply wraps the 'offending' code in a privilege block, making the repro test pass. There's one issue with the test: since I am invoking ij manually from within the fixture, the output gets printed to the console. Does anyone have any suggestions to mute this output? We don't really need to see the output since we can handle the exception instead, in case it throws one. It needs also to be noted that the policy file being used is the already existent util/derby_tests.policy since it serves the purpose of the test. However, a new file (tools/IjSecurityManagerTest.sql) is added that is used to reproduce the failure.
        Dag H. Wanvik made changes -
        Urgency Normal
        Issue & fix info [Newcomer, High Value Fix] [High Value Fix, Newcomer, Repro attached]
        Hide
        Dag H. Wanvik added a comment -

        Triaged for 10.5.2: checked "repro attached" and setting "normal" urgency.

        Show
        Dag H. Wanvik added a comment - Triaged for 10.5.2: checked "repro attached" and setting "normal" urgency.
        Kathey Marsden made changes -
        Attachment derby4292.zip [ 12412337 ]
        Hide
        Kathey Marsden added a comment -

        The problem occurs when you specify a file to run on the ij command line when running under security manager.

        Attached is a reproduction for this issue. Unzip derby4292.zip. Change run.sh to point to your location and run run.sh.

        With the Sun JDK 1.6 JDK I get.
        Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission repro.sql read)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
        at java.io.FileInputStream.<init>(FileInputStream.java:100)
        at java.io.FileInputStream.<init>(FileInputStream.java:66)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:117)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
        at org.apache.derby.tools.ij.main(ij.java:59)

        With IBM 1.6 I don't get an error but I think that is due to an IBM jvm bug which I will file soon.

        Show
        Kathey Marsden added a comment - The problem occurs when you specify a file to run on the ij command line when running under security manager. Attached is a reproduction for this issue. Unzip derby4292.zip. Change run.sh to point to your location and run run.sh. With the Sun JDK 1.6 JDK I get. Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission repro.sql read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.FileInputStream.<init>(FileInputStream.java:100) at java.io.FileInputStream.<init>(FileInputStream.java:66) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:117) at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) at org.apache.derby.tools.ij.main(ij.java:59) With IBM 1.6 I don't get an error but I think that is due to an IBM jvm bug which I will file soon.
        Tiago R. Espinha made changes -
        Assignee Tiago R. Espinha [ espinha ]
        Dag H. Wanvik made changes -
        Issue & fix info [Newcomer] [High Value Fix, Newcomer]
        Dag H. Wanvik made changes -
        Issue & fix info [High Value Fix] [Newcomer]
        Dag H. Wanvik made changes -
        Field Original Value New Value
        Issue & fix info [High Value Fix]
        Kathey Marsden created issue -

          People

          • Assignee:
            Tiago R. Espinha
            Reporter:
            Kathey Marsden
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development