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 11:37:17 GMT


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