harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Date Fri, 20 Jan 2006 12:12:05 GMT
I'll race ya' :-)



Geir Magnusson Jr wrote:
> 
> 
> Tim Ellison wrote:
>> Good -- so what I'll do is to release George's patch to the com.ibm
>> version to get him working, on the understanding that the whole type
>> will become obsolete soon when the security2 code is integrated.  Ok?
> 
> sure, but how long will it take us to integrate?  We should just do that
> ASAP.
> 
> geir
> 
>>
>> Regards,
>> Tim
>>
>> Stepan Mishura wrote:
>>> Hi George,
>>>
>>>> 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.
>>>>
>>> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
>>> that is
>>> from the security component.
>>> BTW, we do have another implementation of java.security.Policy that is
>>> org.apache.harmony.security.fortress.DefaultPolicy and
>>> I've verified that in this particular case implementation from
>>> 'security2'
>>> works correctly.
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 1/20/06, George Harley (JIRA) <jira@apache.org> wrote:
>>>>     [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>>>
>>>> George Harley updated HARMONY-35:
>>>> ---------------------------------
>>>>
>>>>    Attachment: HARMONY-35-patch.txt
>>>>
>>>> The attached patch seems to fix it for me on Win XP. Not tested on
>>>> Linux.
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>> 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
>>>>>  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:
>>>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>>> -
>>>> For more information on JIRA, see:
>>>>   http://www.atlassian.com/software/jira
>>>>
>>>>
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message