Daniel John Debrunner <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> Daniel John Debrunner <[EMAIL PROTECTED]> writes: > >>>Why do you need to grant permissions to read all files for the >>>derbyTesting and junit jars? >> >> >> I'm sorry, but I think you need to ask the junit developers about >> that. I don't know exactly which files junit wants to access, but the >> last error I saw (before granting read access to all files), was an >> access exception because junit was trying to read my home directory to >> figure out if there was a junit.properties file there, I think. I >> don't really understand why derbyTesting.jar needs the same access, >> but I assume it is because the Bugs class (which inherits TestCase) >> ends up there... >> >> I guess it is possible to find the minimal set of file and property >> rights needed by junit, either by reading the junit source, or through >> trial and error, but given the comment in the policy file about not >> trying to make the test harness secure, I didn't think it was worth >> it... > > Just trying to understand it. Adding broad permissions, in my mind, > increases the chance of a SecurityManager related bug being hidden. > > I think derbyTesting.jar would need the permission because it is in the > calling stack of the junit code, and the junit code is not coded to use > privileged blocks. I don't think it would have anything to do with the > Bugs class, but what do you mean by it "ends up there"? Is junit copying > classes out of derbyTesting.jar?
No, I only meant that the .class file resulting from compiling junitTests/lang/Bugs.java is put into derbyTesting.jar when you build derby: jar -tf ~/derby-85_sane_jars/derbyTesting.jar | egrep Bugs org/apache/derbyTesting/functionTests/tests/junitTests/lang/Bugs.class This happened automatically when I added the new file, without changing any build.xml files, (but I had to modify a build.xml file to get the property file added to the jar file). And since the Bugs class inherits from TestCase I thought maybe it pulled some Junit code with it into derbyTesting.jar... But maybe that's just me thinking in C++ again. In Java I guess you resolve all references to the parent class(es) at runtime...? -- dt
