JDK-4286238 : exitVM security property not working
  • Type: Bug
  • Component: docs
  • Sub-Component: guides
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_7,windows_nt
  • CPU: generic,x86
  • Submitted: 1999-10-29
  • Updated: 2001-08-02
  • Resolved: 2001-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
1.4.0 beta2Fixed
Related Reports
Duplicate :  

Name: sg39081			Date: 10/29/99

It is my belief that this is a bug, as it allows code downloaded
into an application to mount a DOS attack by simply killing the
application. This is documented in the JDK API, but does not seem
to work like the rest of the security checks.

//In the code, I don't setup a security manager, as this is done
//by specifying the java.security.manager property at the command

//Note: The JavaDoc for the JDK states in Runtime.exit() that:-
  "throws SecurityException - If a security manager is present and its
  checkExit method does not permit exiting with the specified status"

This means that a call to System.exit(0) which merely delegates to
Runtime.exit() should first check for the appropriate permissions and
throw a security exception or AccessControlException if that permission
does not exit.

   public static void main( String[] args ) throws Exception {
      //We could setup a security manager here, or do it on the
      //cmd line.
      //Example of doing it here.
      //System.setSecurityManager( new SecurityManager() );

      //This fails if the appropriate permission is left out of
      //mypolicy. The failure is an AccessControlException.
      System.getProperty("java.home", "not specified");
      //This should fail since that permission is not granted.
      System.exit( 0 );

//Here, we specify that the default security manager should be used, and
//that the policies should include the "mypolicy" file.
Cmd Line> java -Djava.security.policy=mypolicy -Djava.security.manager tests.SecurityTest

//This is the policy file. Note the lack of a permission, namely,
// permission java.lang.RuntimePermission "exitVM";
//According to the docs, this should result in a security exception
//being thrown when the appropriate System.exit() method is called.
>policy file = mypolicy
grant codeBase "file:/d:/work/java/-" {
  permission java.util.PropertyPermission "java.*", "read";

>java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

>java -fullversion
java full version "1.3beta-O"
(Review ID: 96704) 

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2

WORK AROUND Name: sg39081 Date: 10/29/99 Subclass SecurityManager and overload checkExit method. ======================================================================

EVALUATION mayank.upadhyay@eng 1999-11-01 In sun/misc/Launcher.java the inner class AppClassLoader grants the exitVM permission in its getPermissions() method. While this permission may be desirable during class loading it should not remain in effect later on. sun.applet.AppletClassLoader does not do the same. mayank.upadhyay@eng 2000-02-07 This will be reclassified as a doc bug. See the following: ================= I don't agree with the bug evaluation. I think it was intended that classes defined by the Application/System class loader would be granted exitVM permission -- not just temporarily during class loading. I believe it was felt that applications should be able to terminate themselves but that code loaded from other loader instances such as AppletClassLoader or other URLClassLoaders should not be granted this permission by default. The bug report claims: > It is my belief that this is a bug, as it allows code downloaded > into an application to mount a DOS attack by simply killing the > application. However, I doubt that this is actually true and the example given in the bug description only shows an application exiting. I think the bug submitter was confused about why the System.exit() was succeeding. It wasn't because SecurityManager.checkExit() is broken, instead it is because we explicitly grant permission to exit the VM to any class loaded from the application class path. Downloaded code would normally be loaded by a class loader other than the system/application class loader. This should probably be closed as "not a bug" or should be mutated into a bug against our javadoc to note that "exitVM" permission is automatically granted to all code loaded from the application class path. We make a similar mention about auto-granted permissions in java.io.FilePermission and java.net.URLClassLoader. Since the class which grants the permissions, sun.misc.Launcher.AppClassLoader, is not public we should probably then add the note to RuntimePermission. Jeff ================== Is this workarrounds ok? There still the requirement to "withdraw" some of the default permissions granted to Java application. The attached code is my workarround to create so called a "anti-exitVM" permisstion. The code is for the evaluation, if possible. Hope we have a chance to discussion this issue with someone there. ###@###.### 2002-04-17 ================================