[ http://issues.apache.org/jira/browse/DERBY-1487?page=comments#action_12427147 ] Andrew McIntyre commented on DERBY-1487: ----------------------------------------
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. > Use of getCanonicalPath() in sysinfo causes a SecurityException > --------------------------------------------------------------- > > Key: DERBY-1487 > URL: http://issues.apache.org/jira/browse/DERBY-1487 > Project: Derby > Issue Type: Bug > Components: Tools > Affects Versions: 10.2.0.0, 10.1.3.1 > Environment: Windows XP. I could not reproduce the issue on Mac OS X. > Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre > Priority: Minor > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
