Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <43D01287.9060408@pobox.com>
Date: Thu, 19 Jan 2006 17:28:23 -0500
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-35) Harmony ignores java.security.policy
 property
References: 
 <OF6A681E1B.428C0B07-ON802570FB.0078D254-802570FB.0078FE11@uk.ibm.com>
In-Reply-To: 
 <OF6A681E1B.428C0B07-ON802570FB.0078D254-802570FB.0078FE11@uk.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I suspected :)

George Harley1 wrote:
> 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
>>
>>
> 
> 
>