JDK-4219806 : (thread) CheckAccess() throws invalid SecurityException for Applet
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1.7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-03-12
  • Updated: 2005-09-08
  • Resolved: 2005-09-08
Related Reports
Duplicate :  
Description
Name: mf23781			Date: 03/12/99


If an Applet attempts to stop or interrupt a Thread which it owns, (i.e. the Thread
belongs to the same ThreadGroup as the AppletClassLoader), but the Thread
has already stopped (e.g. because its run() method has terminated) then the
SecurityManager's checkAccess() method throws a SecurityException.

This regression occurs for Thread.stop() and Thread.interrupt(). It could, potentially,
occur for other Thread methods.


Why does this Regression Occur ?
--------------------------------------------------------
The SecurityException thrown during a Thread.stop() has been introduced by a
change which Sun made to this method (Sun defect: 4164156).

This change was made to close a security exposure in the original implementation.
Originally, Thread.stop() called Thread.stop(Throwable o) **THUS ADDING 1**
to the *classLoaderDepth*. 4164156 changed Thread.stop() so that it no longer called 
Thread.stop(Throwable o), thus making the classLoaderDepth when it reached
the SecurityManager's checkAccess() method == 3 (rather than 4).

If a SecurityManager's checkAccess() method finds that the classLoaderDepth == 3,
then it carries on with its validation and checks if the Thread we are trying to
change belongs to the same ThreadGroup as the AppletClassLoader.

When a Thread stops then Thread.exit() sets the ThreadGroup variable "group" =
null i.e. the Thread is no longer in any ThreadGroup and any validation of the
ThreadGroup is futile. 



Test Case for Thread.stop()
------------------------------------------
The Sun 1.0.2 SortDemo illustrates the problem of the Thread.stop() (someone obviously 
noticed the problem in 1.1 since the 1.1 SortDemo patches over the problem by not
attempting to stop the sort Thread !).

1. Run the 1.0.2 SortDemo (e.g. run x:\jdk1.1.6\demo\SortDemo\example1.html) against
a 1.1.7 JDK.
2. Click on the three SortDemo Applets to start them sorting.
3. Wait until the SortDemo Applets have finished sorting.
4. On any of the Applet's:
    Click on "Applet"
    Click on "Stop"
5. This results in: sun.applet.AppletSecurityException checkaccess.thread.


Test Case for Thread.interrupt()
------------------------------------------------
As above, but change the kicker.stop() to kicker.interrupt() in the SortItem.stop()
method.


Where was this problem discovered ?
-----------------------------------------------------------
An application started getting SecurityExceptions when attempting to 
interrupt or stop Threads which had already stopped.


(Review ID: 55468)

======================================================================

Comments
EVALUATION The root cause of this class of problems is that thread termination results in a thread being removed from its thread group. This causes the sun.applet.AppletSecurity to block access. The problem reported with stopping terminated threads was resolved by CR 4496540 (which caused avoidance of use of AppletSecurity for not alive threads). The problem with interrupting terminated threads is a duplicate of 4254486. The fix of 4254486 will take care of all the other Thread methods that would behave the way interrupt() does in the description. ~ ~
08-09-2005

SUGGESTED FIX The Licensee has the following fix in their 1.1.7 : Fix ---- It is very debateable whether a Thread's ThreadGroup ought to be null after it has stopped and ***the design of Thread stopping ought to be investigated***. I fixed the unnecessary SecurityExceptions by catching them in Thread.stop() and Thread.interrupt() as follows: try { checkAccess(); } catch(SecurityException se) { if ( (getThreadGroup() != null) ) throw se; else return; }
11-06-2004