You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ruth Cao <ru...@gmail.com> on 2007/03/07 02:55:27 UTC
[classlib][security] incorrect assertion in tests.api.java.security.PermissionCollectionTest?
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.
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.
Re: [classlib][security] incorrect assertion in tests.api.java.security.PermissionCollectionTest?
Posted by Stepan Mishura <st...@gmail.com>.
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
Re: [classlib][security] incorrect assertion in tests.api.java.security.PermissionCollectionTest?
Posted by Stepan Mishura <st...@gmail.com>.
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.
Yes, please file a JIRA and to fix 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?
> >>
> >> Thanks,
> >> Stepan Mishura
> >> Intel Enterprise Solutions Software Division
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index:
> src/test/api/java/tests/api/java/security/PermissionCollectionTest.java
> > ===================================================================
> > ---
> src/test/api/java/tests/api/java/security/PermissionCollectionTest.java
> (revision 515400)
> > +++
> src/test/api/java/tests/api/java/security/PermissionCollectionTest.java
> (working copy)
> > @@ -57,7 +57,7 @@
> > /**
> > * @tests java.security.PermissionCollection#implies(
> java.security.Permission)
> > */
> > - public void test_impliesLjava_security_Permission() {
> > + public void test_impliesLjava_security_Permission() throws
> Exception {
> >
> > // Look for the tests classpath
> > URL classURL = this.getClass
> ().getProtectionDomain().getCodeSource()
> > @@ -78,7 +78,18 @@
> > try {
> > FileOutputStream fileOut = new
> FileOutputStream(policyFile);
> > String linebreak = System.getProperty("line.separator");
> > - String towrite = "grant codeBase \""
> > + String towrite = "grant {"
> > + + linebreak
> > + + "permission java.io.FilePermission \""
> > + + signedBKS.getFile() + "\", \"read\";"
> > + + linebreak
> > + + "permission java.lang.RuntimePermission\"getProtectionDomain\";"
> > + + linebreak
> > + + "permission java.security.SecurityPermission\"getPolicy\";"
> > + + linebreak
> > + + "};"
> > + + linebreak
> > + + "grant codeBase \""
> > + signedBKS.toExternalForm()
> > + "\" signedBy \"eleanor\" {"
> > + linebreak
> > @@ -96,7 +107,8 @@
> > + linebreak + "};" + linebreak + "grant codeBase
> \"";
> > towrite += classURL.toExternalForm();
> > towrite += "\" {" + linebreak
> > - + "permission java.security.AllPermission;" +
> linebreak
> > + + "permission java.security.AllPermission;"
> > + + linebreak
> > + "};" + linebreak + "keystore \""
> > + keystoreBKS.toExternalForm()
> > + "\",\"BKS\";";
> > @@ -150,44 +162,36 @@
> > + e);
> > }
> >
> > - try {
> > - String result = Support_Exec.execJava(args, classPathArray,
> true);
> > - // Delete the Jar file copied in the user directory
> > - if (!jarFile.delete()) {
> > - throw new IOException("Could not delete temporary jar
> file : "
> > - + jarFile.getPath());
> > - }
> > +
> > + String result = Support_Exec.execJava(args, classPathArray,
> true);
> > + // Delete the Jar file copied in the user directory
> > + if (!jarFile.delete()) {
> > + throw new IOException("Could not delete temporary
> jar file : "
> > + + jarFile.getPath());
> > + }
> >
> > - // Delete the temporary policy file
> > - if (!policyFile.delete()) {
> > - throw new IOException(
> > - "Could not delete temporary policy file : "
> > - + policyFile.getPath());
> > - }
> > + // Delete the temporary policy file
> > + if (!policyFile.delete()) {
> > + throw new IOException("Could not delete temporary
> policy file : "
> > + + policyFile.getPath());
> > + }
> >
> > - StringTokenizer resultTokenizer = new
> StringTokenizer(result, ",");
> > + StringTokenizer resultTokenizer = new
> StringTokenizer(result, ",");
> >
> > - // Check the test result from the new VM process
> > - assertEquals("Permission should be granted", "true",
> > - resultTokenizer.nextToken());
> > - assertEquals("signed Permission should be granted", "true",
> > - resultTokenizer.nextToken());
> > - assertEquals("Permission should not be granted", "false",
> > - resultTokenizer.nextToken());
> > - } catch (IOException e) {
> > - fail("IOException during test : " + e);
> > - } catch (InterruptedException e) {
> > - fail("InterruptedException during test : " + e);
> > - } catch (NoSuchElementException e) {
> > - fail("NoSuchElementException during test : " + e);
> > - } catch (Exception e) {
> > - fail("Exception during test : " + e);
> > - }
> > + // Check the test result from the new VM process
> > + assertEquals("Permission should be granted", "true",
> resultTokenizer
> > + .nextToken());
> > + assertEquals("signed Permission should be granted",
> "true",
> > + resultTokenizer.nextToken());
> > + assertEquals("Permission should not be granted", "false",
> > + resultTokenizer.nextToken());
> > +
> > }
> >
>
>
> --
> Regards,
>
> Ruth Cao
> China Software Development Lab, IBM
>
>
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [classlib][security] incorrect assertion in tests.api.java.security.PermissionCollectionTest?
Posted by Ruth Cao <ru...@gmail.com>.
If no one objects, I'll raise a JIRA and create a patch to let the test
pass on both RI and Harmony. Thanks.
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?
>>
>> Thanks,
>> Stepan Mishura
>> Intel Enterprise Solutions Software Division
>>
>
>
> ------------------------------------------------------------------------
>
> Index: src/test/api/java/tests/api/java/security/PermissionCollectionTest.java
> ===================================================================
> --- src/test/api/java/tests/api/java/security/PermissionCollectionTest.java (revision 515400)
> +++ src/test/api/java/tests/api/java/security/PermissionCollectionTest.java (working copy)
> @@ -57,7 +57,7 @@
> /**
> * @tests java.security.PermissionCollection#implies(java.security.Permission)
> */
> - public void test_impliesLjava_security_Permission() {
> + public void test_impliesLjava_security_Permission() throws Exception {
>
> // Look for the tests classpath
> URL classURL = this.getClass().getProtectionDomain().getCodeSource()
> @@ -78,7 +78,18 @@
> try {
> FileOutputStream fileOut = new FileOutputStream(policyFile);
> String linebreak = System.getProperty("line.separator");
> - String towrite = "grant codeBase \""
> + String towrite = "grant {"
> + + linebreak
> + + "permission java.io.FilePermission \""
> + + signedBKS.getFile() + "\", \"read\";"
> + + linebreak
> + + "permission java.lang.RuntimePermission \"getProtectionDomain\";"
> + + linebreak
> + + "permission java.security.SecurityPermission \"getPolicy\";"
> + + linebreak
> + + "};"
> + + linebreak
> + + "grant codeBase \""
> + signedBKS.toExternalForm()
> + "\" signedBy \"eleanor\" {"
> + linebreak
> @@ -96,7 +107,8 @@
> + linebreak + "};" + linebreak + "grant codeBase \"";
> towrite += classURL.toExternalForm();
> towrite += "\" {" + linebreak
> - + "permission java.security.AllPermission;" + linebreak
> + + "permission java.security.AllPermission;"
> + + linebreak
> + "};" + linebreak + "keystore \""
> + keystoreBKS.toExternalForm()
> + "\",\"BKS\";";
> @@ -150,44 +162,36 @@
> + e);
> }
>
> - try {
> - String result = Support_Exec.execJava(args, classPathArray, true);
> - // Delete the Jar file copied in the user directory
> - if (!jarFile.delete()) {
> - throw new IOException("Could not delete temporary jar file : "
> - + jarFile.getPath());
> - }
> +
> + String result = Support_Exec.execJava(args, classPathArray, true);
> + // Delete the Jar file copied in the user directory
> + if (!jarFile.delete()) {
> + throw new IOException("Could not delete temporary jar file : "
> + + jarFile.getPath());
> + }
>
> - // Delete the temporary policy file
> - if (!policyFile.delete()) {
> - throw new IOException(
> - "Could not delete temporary policy file : "
> - + policyFile.getPath());
> - }
> + // Delete the temporary policy file
> + if (!policyFile.delete()) {
> + throw new IOException("Could not delete temporary policy file : "
> + + policyFile.getPath());
> + }
>
> - StringTokenizer resultTokenizer = new StringTokenizer(result, ",");
> + StringTokenizer resultTokenizer = new StringTokenizer(result, ",");
>
> - // Check the test result from the new VM process
> - assertEquals("Permission should be granted", "true",
> - resultTokenizer.nextToken());
> - assertEquals("signed Permission should be granted", "true",
> - resultTokenizer.nextToken());
> - assertEquals("Permission should not be granted", "false",
> - resultTokenizer.nextToken());
> - } catch (IOException e) {
> - fail("IOException during test : " + e);
> - } catch (InterruptedException e) {
> - fail("InterruptedException during test : " + e);
> - } catch (NoSuchElementException e) {
> - fail("NoSuchElementException during test : " + e);
> - } catch (Exception e) {
> - fail("Exception during test : " + e);
> - }
> + // Check the test result from the new VM process
> + assertEquals("Permission should be granted", "true", resultTokenizer
> + .nextToken());
> + assertEquals("signed Permission should be granted", "true",
> + resultTokenizer.nextToken());
> + assertEquals("Permission should not be granted", "false",
> + resultTokenizer.nextToken());
> +
> }
>
--
Regards,
Ruth Cao
China Software Development Lab, IBM
Re: [classlib][security] incorrect assertion in tests.api.java.security.PermissionCollectionTest?
Posted by Ruth Cao <ru...@gmail.com>.
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?
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>
--
Regards,
Ruth Cao
China Software Development Lab, IBM
Re: [classlib][security] incorrect assertion in tests.api.java.security.PermissionCollectionTest?
Posted by Stepan Mishura <st...@gmail.com>.
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)
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?
Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division