See the attached URL for an example; grant your trust to the applet, then close the applet's window (which will cause the applet to call System.exit()), which will (incorrectly) crash/quit the browser. This happens on 0.9.9, Win32 and Linux. I'm posting this with Galeon, which is why the browser detection doesn't match up. The correct behavior would be to unload the jvm plugin .dll/.so and reload it, restarting the jvm plugin rather than the entire browser.
Works for me ! Using JRE 1.4.0 and Mozilla 2002033109 under WinXP.
More info : when I close java window, it closes also Mozilla !
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Patrick -- any suggestions on this one?
Assignee: beppe → beard
Need a stack crawl. Reassigning to Sun engineer.
Assignee: beard → joe.chou
Browser exits because java plugin exit (and pipe to browser side is closed, etc.). This is jpi problem because applets should not be allowed to call System.exit() in any circumstances. See item 11 of java security faq http://java.sun.com/sfaq/. Steve - looks like this your area. BTW, moving to OJI.
Component: Plug-ins → OJI
> This is jpi problem because applets should not be allowed to > call System.exit() in any circumstances. See item 11 of > java security faq: http://java.sun.com/sfaq/ Hrm, doesn't it mean that *untrusted* applets shouldn't be able to do that? The test case is a signed applet which (AFAIK) should run with full permissions (provided it wraps dangerous calls in doPriviledged()'s) Also, the link above is for jdk1.1 (see the first paragraph), which had a totally different security architecture. If I recall correctly, the distinction between applets loaded off the filesystem vs applets loaded off the network was erased in jdk1.2 (both are untrusted unless signed and approved by the user). To increase the confusion level even further, check out point #13: > applets loaded via the file system are allowed to exit the > virtual machine Which directly contradicts #11: > In particular, this means that applets can't invoke some > program to list the contents of your file system, and it > means that applets can't invoke System.exit() in an attempt > to kill your web browser. Quite confusing! =) Is there an updated Apple Security FAQ for jdk1.2+? If so, perhaps we could go by that.
I do not think there is an updated FAQ because this one is referenced from java plugin documentation. Personally i do not fill System.exit from (signed or not) applet should not work because it not just exits jvm of this applet because _same_ jvm is used to run other applets in other windows.
> Personally i do not fill System.exit from (signed or not) applet > should not work because it not just exits jvm of this applet > because same jvm is used to run other applets in other windows. Hrm, how else can an applet force all of its classes to unload? The main concern is that there should be a way for an applet to ensure that if the user visits the applet a second time, without closing the browser, that all classes are reloaded and all class initializers are re-run.
xiaobin: may be you can clarify what is expected behavior here?
I believe the same rule against applets invoking System.exit() still applies. System.exit() is defined to call Runtime.exit(). The specification for Runtime.exit() makes it clear that the SecurityManager has a right to deny the call to Runtime.exit() (and transitively, System.exit()) _for any reason_. Also, all applets are required to run under a security manager. This means that the Plug-in's security manager can refuse all calls to System.exit() and be well within the specification. If you think about the architecture of Sun's plug-in and the specification of Runtime.exit(), you will see that it doesn't make sense to allow applets to call Runtime.exit (System.exit()). That is because Runtime.exit() is defined to shut down the _entire_ JVM, not just exit the application (applet). Sun's plug-in is designed to run all applets in a single JVM. That means, at a minimum, you would terminate _all_ applets on all web pages with a single applet's call to System.exit(). On Windows, the JVM is designed so that it will only terminate once (after the browser has stopped). Furthermore, the applet security documentation states that applets aren't allowed to manipulate threads outside their threadgroups. Obviously, terminating every thread in the JVM is well outside this rule. Note also that the documentation doesn't distinguish between signed and unsigned applets when defining the behavior described above. The restrictions apply regardless of whether the applet has been signed. It is analogous to the servlet specification: even a servlet in a signed Jar cannot call System.exit() (they can't even create threads!). So, in conclusion, the Sun JPI's security manager should be throwing a SecurityException from Runtime.exit()/System.exit() whenever it is invoked by an applet.
I have created a simpler testcase with source code. Building the tests: javac *.java jar -cf SystemExitApplet.jar *.class *.html *.java jarsigner -storepass anyany SystemExitApplet.jar tstkey (assuming you have an alias "tstkey" in your keystore with password "anyany") Running the tests: Download the testcase (SystemExitApplet.jar). Run "jar -xf SystemExitApplet.jar" to extract the HTML pages and source code Test A: 1. Open SystemExitInit.html in Mozilla. Grant permission for the session when Mozilla asks you to. Expected result: SecurityException (see console) Actual result: All Mozilla windows and all applet windows close. The mozilla process has terminated. Test B: 1. Open SystemExitButton.html in Mozilla. 2. Grant permission for the session when Mozilla asks you to. 3. Click the button. Expected result: SecurityException (see console) Actual result: All Mozilla windows and all applet windows close The mozilla process has terminated. The HTML pages are included inside the signed JAR file. The same behavior occurs in Internet Explorer 5.5 also. I tested on JPI 1.4.0 / Mozilla 2002042608 / Windows 2000 SP2
Notice that the applet doesn't have to be signed, if it is run from local filesystem. I'm also experiencing crashes when accessing the System.exit() applet which is not signed. You can test it at http://olo.office.altkom.com.pl/domowa/mozilla/system_exit/ . Just visit the page and click on the link to SystemExitTestApplet.html. The crashes are reproducible with win32 trunk build 2002060908 running on Windows 2000. My applet is a very simplified testcase, you can find the source in the JAR archive. It simply calls System.exit(1); from its init() method.
reassign to me
Assignee: joe.chou → joshua.xia
WFM on Linux(RH8.0)/Windows2000 mozilla1.2 JRE1.4.1_01 I got following exception in my java console: ========================= java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:542) at java.lang.SecurityManager.checkExit(SecurityManager.java:762) at java.lang.Runtime.exit(Runtime.java:88) at java.lang.System.exit(System.java:713) at pl.com.altkom.office.olo.Testcases.SystemExitTestApplet.init(SystemExitTestApplet.java:5) at sun.applet.AppletPanel.run(AppletPanel.java:347) at java.lang.Thread.run(Thread.java:536) ======================= So, I think this has been fixed in latest JRE. Closing
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.