Derby
  1. Derby
  2. DERBY-1487

Use of getCanonicalPath() in sysinfo causes a SecurityException

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.1.3.1, 10.2.1.6
    • Fix Version/s: None
    • Component/s: Tools
    • Environment:
      Windows XP. I could not reproduce the issue on Mac OS X.
    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached

      Description

      From DERBY-1272:

      Here's the full stack for the SecurityException found by the errorStream test with the -v4 patch applied:

      Test errorStream failed: access denied (java.io.FilePermission C:\derby-trunk\classes read)
      at java.security.AccessController.checkPermission(AccessController.java:401)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
      at java.lang.SecurityManager.checkRead(SecurityManager.java:863)
      at java.io.File.exists(File.java:678)
      at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:360)
      at java.io.File.getCanonicalPath(File.java:513)
      at org.apache.derby.impl.tools.sysinfo.Main.formatURL(Main.java:1206)
      at org.apache.derby.impl.tools.sysinfo.Main.loadZipFromResource(Main.java:831)
      at org.apache.derby.impl.tools.sysinfo.Main.getAllInfo(Main.java:735)
      at org.apache.derby.impl.tools.sysinfo.Main.reportDerby(Main.java:212)
      at org.apache.derby.impl.tools.sysinfo.Main.getMainInfo(Main.java:119)
      at org.apache.derby.tools.sysinfo.getInfo(sysinfo.java:200)
      at org.apache.derby.impl.services.monitor.BaseMonitor.dumpTempWriter(BaseMonitor.java:1949)
      at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:383)
      at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor.java:59)
      at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288)
      at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:68)
      at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:178)

      The problem would appear that we explicitly need java.io.FilePermission read on the classes directory, even though this directory contains the classes we are currently running against. This may be a problem with java.io.File.getCanonicalPath(), but it may also be a problem with sysinfo.

      org.apache.derby.impl.tools.sysinfo.Main.formatURL(Main.java:1206) is:

      result = new File(filename).getCanonicalPath().replace('/', File.separatorChar);

      The Sun Windows JVM may throw a SecurityException by default in the most restricted environments. From the javadoc for File.getCanonicalPath():

      "If a required system property value cannot be accessed, or if a security manager exists and its SecurityManager.checkRead(java.io.FileDescriptor) method denies read access to the file"

      Some investigation is required to determine whether or not this is a Windows-specific issue or if it is reproducible on other platforms. It has already been found to not be reproducible on Mac OS X. I'm curious why this exception is not thrown when running sysinfo standalone with a security manager without a policy file, since presumably this permission would not have been granted to sysinfo and the same code path should be used in both cases.

      1. DERBY-1487_repro.diff
        23 kB
        Myrna van Lunteren

        Issue Links

          Activity

          Hide
          Andrew McIntyre added a comment -

          I haven't had much time to work on this issue, but the security docs say this about java.io.FilePermission:

          "Note: code can always read a file from the same directory it's in (or a subdirectory of that directory); it does not need explicit permission to do so."

          However, the code that fails, as represented in the stack trace in JIRA above, with "access denied (java.io.FilePermission C:\derby-trunk\classes read)", is in the same directory that is attempting to be accessed: from the test code, to the engine, to sysinfo. So I'm at a loss at the moment as to why a security exception is thrown at this point. We could catch the exception in sysinfo, but because the test passes on non-Windows platforms, I think the problem really lies somewhere else, either in sysinfo, our policy file for the tests, in the test, or maybe even in the JDK.

          Since this issue blocks DERBY-1272, if there is no insight into this issue from others in a couple of days, I will push both this and DERBY-1272 out to a future release.

          Show
          Andrew McIntyre added a comment - I haven't had much time to work on this issue, but the security docs say this about java.io.FilePermission: "Note: code can always read a file from the same directory it's in (or a subdirectory of that directory); it does not need explicit permission to do so." However, the code that fails, as represented in the stack trace in JIRA above, with "access denied (java.io.FilePermission C:\derby-trunk\classes read)", is in the same directory that is attempting to be accessed: from the test code, to the engine, to sysinfo. So I'm at a loss at the moment as to why a security exception is thrown at this point. We could catch the exception in sysinfo, but because the test passes on non-Windows platforms, I think the problem really lies somewhere else, either in sysinfo, our policy file for the tests, in the test, or maybe even in the JDK. Since this issue blocks DERBY-1272 , if there is no insight into this issue from others in a couple of days, I will push both this and DERBY-1272 out to a future release.
          Hide
          Myrna van Lunteren added a comment - - edited

          [Triage 10.5.2] I looked into this issue a little, seeing if I can still reproduce it.
          And I can - but it's gotten quite convoluted.

          I applied the changes from patch 1272_v4 individually, and copied the old errorStream* test files from a 10.3 branch - errorStream test was converted into junit (under engine, see DERBY-3156), and I preferred to get the original repro rather than mess with it and possibly missing the repro because of changes in the test. Then added the new errorStream_derby.properties file. Build, and got the failure upon running the test.

          However, after clobber, ant all result suggests the build was successfull, but showed the following build trouble:
          compile_mbeans:
          [javac] Compiling 4 source files to C:\derbyt\svn\trunk\classes
          [javac] <...mypath_to_trunk...>\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1974: package org.apache.derby.tools does not exist
          [javac] org.apache.derby.tools.sysinfo.getInfo(systemStreams.stream().getPrintWriter());
          [javac] ^
          [javac] <...mypath_to_trunk...>\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1976: package org.apache.derby.tools does not exist
          [javac] org.apache.derby.tools.sysinfo.getInfo(getTempWriter());
          [javac] ^
          [javac] 2 errors
          [javac] Compile failed; see the compiler error output for details.
          Not sure why that wouldn't cause the build to fail...

          I also tried to compile with just the changes of the failed commit 592590 - i.e., no change to impl/services/build.xml - but that too gave the same build trouble, and this time the build failed.

          The test still ran and failed as before even though the build failed.

          Show
          Myrna van Lunteren added a comment - - edited [Triage 10.5.2] I looked into this issue a little, seeing if I can still reproduce it. And I can - but it's gotten quite convoluted. I applied the changes from patch 1272_v4 individually, and copied the old errorStream* test files from a 10.3 branch - errorStream test was converted into junit (under engine, see DERBY-3156 ), and I preferred to get the original repro rather than mess with it and possibly missing the repro because of changes in the test. Then added the new errorStream_derby.properties file. Build, and got the failure upon running the test. However, after clobber, ant all result suggests the build was successfull, but showed the following build trouble: compile_mbeans: [javac] Compiling 4 source files to C:\derbyt\svn\trunk\classes [javac] <...mypath_to_trunk...>\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1974: package org.apache.derby.tools does not exist [javac] org.apache.derby.tools.sysinfo.getInfo(systemStreams.stream().getPrintWriter()); [javac] ^ [javac] <...mypath_to_trunk...>\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1976: package org.apache.derby.tools does not exist [javac] org.apache.derby.tools.sysinfo.getInfo(getTempWriter()); [javac] ^ [javac] 2 errors [javac] Compile failed; see the compiler error output for details. Not sure why that wouldn't cause the build to fail... I also tried to compile with just the changes of the failed commit 592590 - i.e., no change to impl/services/build.xml - but that too gave the same build trouble, and this time the build failed. The test still ran and failed as before even though the build failed.
          Hide
          Myrna van Lunteren added a comment -

          Attaching an updated diff of the patch for 1272 which enables repro of the problem in this bug by running the old errorStream test.

          Show
          Myrna van Lunteren added a comment - Attaching an updated diff of the patch for 1272 which enables repro of the problem in this bug by running the old errorStream test.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew McIntyre
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development