[ http://issues.apache.org/jira/browse/DERBY-622?page=comments#action_12372383 ]
Andrew McIntyre commented on DERBY-622: --------------------------------------- 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: DERBY-622 - the only difference in the output was the lack of reporting of the locales. I believe that the other information affected by this change, the location of the derby classes and the build number, have been filtered out by Sed.java 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. > sysinfo incorrectly requires permission on Derby jar files > ---------------------------------------------------------- > > Key: DERBY-622 > URL: http://issues.apache.org/jira/browse/DERBY-622 > Project: Derby > Type: Bug > Components: Security, Tools > Versions: 10.2.0.0 > Reporter: Daniel John Debrunner > Priority: Minor > Fix For: 10.2.0.0 > Attachments: DERBY-622_step1.diff > > Running the test derbynet/sysinfo.java requires this permission in > derby_tests.policy, in order to read the jar files. > 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.' > Probably means a privileged block is required when accessing the contents of > the jar files in sysinfo -- 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
