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) <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
