db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1487) Use of getCanonicalPath() in sysinfo causes a SecurityException
Date Thu, 10 Aug 2006 08:54:15 GMT
    [ 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:,
>         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
>         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
> 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
> 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


View raw message