[ 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
