|
Without the step 1 patch, and without the lines currently in the derby_tests.policy file for derbynet.jar and derby.jar:
permission java.io.FilePermission "${derbyTesting.codedir}${/}*", "read"; the test will fail with output like this in the .tmp: - - - - - - - - - - - - - - - - - - - - - - - - - ------------------ Java Information ------------------ Java Version: 1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission java.home read) Java classpath: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission java.class.path read) OS name: Windows 2000 OS architecture: x86 OS version: 5.0 Java user name: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission user.name read) Java user home: C:\Documents and Settings\Administrator Java user dir: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read) java.specification.name: Java Platform API Specification java.specification.version: 1.4 --------- Derby Information -------- JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 No Derby System info found! ------------------------------------------------------ ----------------- Locale Information ----------------- ------------------------------------------------------ End test Testing Sysinfo (method) - - - - - - - - - - - - Note that the sed-processing removes the Java info section. With the patch, we see this: - - - - - - - - - - - - ------------------ Java Information ------------------ Java Version: 1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission java.home read) Java classpath: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission java.class.path read) OS name: Windows 2000 OS architecture: x86 OS version: 5.0 Java user name: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission user.name read) Java user home: C:\Documents and Settings\Administrator Java user dir: Security Exception: java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read) java.specification.name: Java Platform API Specification java.specification.version: 1.4 --------- Derby Information -------- JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [/org/apache/derby/info/DBMS.properties] 10.2.0.0 alpha - (384366M) ------------------------------------------------------ ----------------- Locale Information ----------------- ------------------------------------------------------ End test Testing Sysinfo (method) - - - - - - - - - So, not much of an improvement... (Note, by the way, also, that in the mean time we ought to have another line in the derby_tests.policy file for the case that derbytools.jar is the first in the classpath - I guess everyone always puts derby.jar first...) Hi Myrna, that output is unusual, it implies to me that getResourceAsStream is returning null for most of the info properties files. I'll take a closer look at this patch tomorrow.
Committed _step1 patch with revision 390000.
Several comments: 1 - This had no effect on the test(s) in question because I did not commit the policy file change. This change was not included in the patch, but was described in the comments to this issue. I committed this patch because it seemed like an obvious step forward to wrap these calls to getResourceAsStream in priv blocks since they have security implications, and the tests were not affected. 2 - With this change and the policy file change - removing the permissions marked as Bug: 3 - Following the execution of sysinfo in a debugger, with the policy file change, getResourceAsStream() for the locale info properties file returns null with no SecurityException thrown. I had expected a SecurityException to be thrown here, for lacking java.io.FilePermission "read" on the jar file with the locale property file. But in the debugger, it appeared as though the call to getResourceAsStream() was simply skipped over and the InputStream returned from the call is null. This explains why the locale information fails to report any information, but can anyone think of why I might be seeing this behavior? That is, why would the VM simply skip over the call to getResourceAsStream() without throwing a SecurityException? 4 - With the policy file change, and with the privileged blocks, the result is the same as without the privileged blocks. So I am confused as to the nature of this issue. The original description of the issue refers to permissions being granted to codebase csinfo.codedir, which would be the compiled classes in a directory, not the packaged jar files. With or without this change, the behavior is the same with the classes in a directory, because the files in question would be accessible under the security manager by virtue of being in the same location as the rest of the code and test files (csinfo.codedir, now derbyTesting.codeclasses) - as mentioned in the description of the bug. The same is not true with jars because the jars are treated as separate locations and thus the policy for the jar files is specific to each jar (because they are separate locations, unlike having all classes in a single directory), so permission might need to be granted to read from each of the locale jar files, even with the privileged blocks. But, I had thought that the permission currently in derby_tests.policy should allow reading from any jar files in the same location as the jar files from which sysinfo is loaded, but the permissions are apparently not sufficient, or something else is going on. That something else would be the weird skipping over of the call to getResourceAsStream(). So, I'm confused as to what is going on here. Dan, you filed this issue, do you have any insight? Particularly, as to why the calls to getResourceAsStream() are being skipped without a SecurityException being thrown? My next steps are to test granting read permissions to each of the locale jar files specifically, and to find the source to the getResourceAsStream methods and antecedants to see if somehow the SecurityException is being consumed there without being thrown in the JVM that I am currently using. Followup:
I can confirm that both with and without the change in the _step1 patch, and with or without the policy file change to remove the lines marked Bug: permission java.io.FilePermission "${derbyTesting.codejar}derbyLocale_${LOCALE}.jar", read where ${LOCALE} is one of the supported locale jar files removes the corresponding line from the diff in the test. Sorry, mistake in that last comment. Getting late here. :-) It should have read:
I can confirm that with or without the change in the _step1 patch, and *with* the policy file change to remove the lines... Without any changes to the policy file, there is no change in the behavior of the tests, which is why I opted to commit the _step1 patch as-is. Hi Andrew. Whichever way we decide to go on the policy file, let's please make the changes to *all three* of derby.jar, derbynet.jar, and derbytools.jar. This is relevant to
One comment on 3) in Andrew's comment. The specified behaviour for getResourceAsStream is that it returns "null if the resource could not be found or the caller doesn't have adequate privileges to get the resource."
See ClassLoader.getResource(String) Thanks, Dan. That's what I get for looking at the javadoc for the actual method being called. ;-) I think I actually ran into that in a previous issue, too
So, do you think adding the permission to read the locale jar files is the way to go here? Or should we just leave the test the way it is and close this issue? I am closing this issue as fixed. During testing, it became apparent that there were a couple of places in sysinfo that needed privileged blocks, and these were fixed by a patch by Myrna, which I committed with revision 390000.
However, there is now a sysinfo.policy file which grants the permissions that the description of this issue complained should not be necessary. From the description of this issue: ... permission java.io.FilePermission "${csinfo.codedir}${/}*", "read" But according to the Java security specs: '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.' ... This is true for classes in a directory, but for jars, FilePermission to read other jars must be granted explicitly, which is why: grant codeBase "${derbyTesting.codejar}/derbytools.jar" { permission java.io.FilePermission "${derbyTesting.codedir}${/}*", "read"; }; is granted, so that derbytools.jar can read from any other jar file (like the locale jar files) in the directory which it is in. Similar permissions are granted to derby.jar and derbynet.jar, depending on which jar file is first in the classpath, and thus, from which the sysinfo classes are loaded first. The only remaining comment I have is that, in light of the above with regard to the security spec, and the comments attached to this issue, these lines in derbynet/sysinfo.policy seem superfluous: grant codeBase "${derbyTesting.codeclasses}" { // the following two lines shouldn't be needed permission java.io.FilePermission "${derbyTesting.codedir}", "read"; permission java.io.FilePermission "${derbyTesting.codeclasses}${/}*", "read"; }; These lines were granted as part of http://www.nabble.com/Re%3A--jira--Updated%3A-%28DERBY-955%29-Get-derbyall-on-jdk1.6-p3977396.html and the followups. I have tested derbynet/sysinfo.properties and derbynet/sysinfo_withproperties with JDK 1.5 on Mac OS X without the above lines and the tests passed. So, it might be desirable to revisit granting these permissions to the sysinfo tests. This issue has been resolved for over a year with no further movement. Closing.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
sysinfo incorrectly requires permission on Derby jar files
This patch -
DERBY-622_step1.diff - adds privileged blocks around the getResourceAsStream sections in use.This is a first step, it didn't have the result I expected. Maybe someone can review and see if I did something really dumb....