setting the system property -Djava.security.manager should install an applet-like restrictive SecurityManager. Run the attache program with the RI:
roman@moonlight:~/src/test$ /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.security.manager TestProps
Exception in thread "main" java.security.AccessControlException: access denied (java.util.PropertyPermission java.home read)
With Classpath and JamVM this simply spits out the java.home property.
Created attachment 12674 [details]
This report makes no sense and the test case uses an GNU Classpath private class.
I think GCJ/gij has support for this. I'm not sure if this is something we can do properly in Classpath code, or if it requires VM support.
Does the test case mistakenly use SystemProperties when it should use System?
What else about this bug report doesn't make sense? Defining 'java.security.manager' to an empty string is supposed to install a security manager (technically, I think it is the default security manager, which loads the system policy file, NOT an applet-like sandbox).
Sorry, that testcase is wrong. This was supposed to use System.getProperty() instead.
Also, the default Policy loaded by Classpath is useless (it allows everything), so even if defining -Djava.security.manager loads a default security manager, it won't have much of an effect.
Casey is correct that the default Policy loaded is useless, but the -Djava.security.manager option works fine.
public class TestProps
public static void main(String args)
You'll see that the first line does print out a SecurityManager instance when you specify -Djava.security.manager.
So, please close this bug and open a bug on the incorrect policy.