[
https://issues.apache.org/jira/browse/DERBY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731914#action_12731914
]
Myrna van Lunteren edited comment on DERBY-1487 at 7/16/09 5:00 AM:
--------------------------------------------------------------------
[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.
was (Author: myrna):
[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.
Anyway, I'll attach
> Use of getCanonicalPath() in sysinfo causes a SecurityException
> ---------------------------------------------------------------
>
> Key: DERBY-1487
> URL: https://issues.apache.org/jira/browse/DERBY-1487
> Project: Derby
> Issue Type: Bug
> Components: Tools
> Affects Versions: 10.1.3.1, 10.2.1.6
> Environment: Windows XP. I could not reproduce the issue on Mac OS X.
> Reporter: Andrew McIntyre
> Priority: Minor
> Attachments: DERBY-1487_repro.diff
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
