harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Date Fri, 20 Jan 2006 14:39:30 GMT
pointless, but ok.

geir


Tim Ellison wrote:
> 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
>>>>>
>>>>>
> 

Mime
View raw message