harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley1 <GHAR...@uk.ibm.com>
Subject Re: [jira] Created: (HARMONY-35) Harmony ignores java.security.policy property
Date Thu, 19 Jan 2006 22:01:29 GMT
Hi, 

Yep. On its way ....

Best regards, 
George
________________________________________
George C. Harley




Geir Magnusson Jr <geir@pobox.com> 
19/01/2006 21:56
Please respond to
harmony-dev@incubator.apache.org


To
harmony-dev@incubator.apache.org
cc

Subject
Re: [jira] Created: (HARMONY-35) Harmony ignores java.security.policy 
property






have a patch, maybe?

George Harley (JIRA) wrote:
> 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
> 
> 
> 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
> 
> 



Mime
View raw message