harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Ellison (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (HARMONY-35) Harmony ignores java.security.policy property
Date Fri, 20 Jan 2006 16:03:43 GMT
     [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
Tim Ellison resolved HARMONY-35:

    Resolution: Fixed

Fixed in luni module  com/ibm/oti/util/DefaultPolicy.java  at repository revision 370797.

George, please check this fully fixes the problem.

> Harmony ignores java.security.policy property
> ---------------------------------------------
>          Key: HARMONY-35
>          URL: http://issues.apache.org/jira/browse/HARMONY-35
>      Project: Harmony
>         Type: Bug
>   Components: Classlib
>  Environment: Win32 and Linux
>     Reporter: George Harley
>     Assignee: Tim Ellison
>  Attachments: HARMONY-35-patch.txt
> Here is the complete contents of a Java security policy file called "mysecurity.policy"
that can be used to specify additional permissions to a JRE...
> ---------snip----------
> grant {
>     // so we can remove the security manager
>     permission java.lang.RuntimePermission "setSecurityManager";
> };
> ---------snip----------
> If its location is passed in the Java launch arguments with the java.security.policy
property as below then the permissions are added to the default set of permissions that the
JRE runs with ...
> -Djava.security.policy=c:\path\to\mysecurity.policy
> If the following unit test is run against a sandbox build of the classlibs under SVN
trunk on the IBM Apache Harmony VME with the java.security.policy set (as above) so that the
"setSecurityManager" runtime permission is added, then a pass should result. It doesn't. 
> -----------snip--------------
> package foo;
> import java.security.AccessControlException;
> import junit.framework.TestCase;
> public class SecurityPolicyTest extends TestCase {
>     public void testPermissions() {
>         try {
>             System.out
>                     .println("Trying to set the security manager the first time...");
>             System.setSecurityManager(new SecurityManager());
>             System.out.println("Trying to set the security manager to null...");
>             System.setSecurityManager(null);
>             assertEquals(null, System.getSecurityManager());
>         } catch (AccessControlException e) {
>             fail("Caught AccessControlException : " + e.getMessage());
>         }
>     }
> }
> -----------snip--------------
> The failure occurs because an AccessControlException is thrown on the second call to
System.setSecurityManager() when the test tries to pass a null argument.
> The problem is that after the first call to System.setSecurityManager() has installed
a security manager, there is no runtime permission to enable the security manager to be set
again. This is despite the fact that when running the test we set the java.security.policy
property to point to a file that grants this very permission !
> The reason for this buggy behaviour is the incomplete implementation of com.ibm.oti.util.DefaultPolicy
in the luni component. The readPolicy() method needs work to actually fulfill its contract
as laid out in the Javadoc comments. 
> George

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message