On 3/9/07, Ruth Cao wrote:
If no one objects, I'll raise a JIRA and create a patch to let the test pass on both RI and Harmony. Thanks.
Hi Ruth, Sorry, I'm a bit late with reviewing your patch (it have been applied already) - now the test verifies that permissions are not granted. But it looks for me like that a test's author believed that permissions should be granted, am I right? So any ideas what may be wrong in the test? Thanks, Stepan. Ruth Cao wrote:
> Stepan Mishura wrote: >> On 3/7/07, Ruth Cao wrote: >> >>> Hi all, >>> >>> When I'm looking at the exclude lists in the security module, I've >>> found >>> that the test_impliesLjava_security_Permission method in >>> t.a.j.security.PermissionCollectionTest fails on both RI and Harmony. >>> Looking more deeply into the code, I think the main reason may be that >>> the 'coucou.FileAccess' class does not contain certain permission. >>> Thus, >>> the result string on both RI and Harmony is 'false, false, false', >>> which >>> does not equal to the assertion. >> >> >> The test fails on Harmony and RI with: >> java.security.AccessControlException: access denied >> (java.io.FilePermission<abs_path>/signedBKS.jar read) >> > The j.i.FilePermission happens just because the temporary policy file > does not grant enough permission to the program. However, after > modifying the test case a little (pls see the attached patch), I still > got a failure, which indicates the result String returned by > Support_Exec.execJava is 'false, false, false'. So I guess it is due > to the 'coucou.FileAccess'. > > Pls correct me if I'm wrong. Thanks. > >> Why you think that 'coucou.FileAccess' class needs more permissions >> to read >> signedBKS.jar file? >> >>> Is it just a test case code problem or does it need more configuration >>> to run this PermissionCollectionTest? Can any security guru give me >>> some >>> advice or suggestion? Thanks a lot. >>> >> >> Yes, it looks like a test case code problem for me - I can not >> understand >> why PermissionCollection.implies() method is tested in this odd way: >> signed >> jar-file, keystore, dynamically generated policy file, forked VM ....:-) >> (May be I'm missing some nuances). >> Do this testing scenario really tests the method? First of all it's >> abstract >> method so we can test its implementation by some sublass. The test >> invokes >> Policy.getPermissions(ProtectionDomain) method to get >> PermissionCollection >> object but indeed that is instance of java.security.Permissions >> class. So >> why not just simply create Permissions object, add required >> permissions to >> it and test implies() method? >> <SNIP>
-- Stepan Mishura Intel Enterprise Solutions Software Division
