EVALUATION

The fix for this bug requires changes in both the jdk and the deployment code. The deployment changes have already been forwardported to JDK7, from 6u18, as far of CR 	6958606: "Umbrella: Port All 6u15 - 6u21 changes in Deploy workspace to JDK7".

Leaving just the cleanup in the JDK code.
                                     

EVALUATION

CR 6991300: "MimeTable is unsafe" will be used to track the jdk side issue.
                                     

SUGGESTED FIX

diff AppletViewer.javaORIG AppletViewer.java
522,539d521
<         
<         /* we reference this class to get it loaded
<          * from a class w/o a classloader.  If not,
<          * it first gets loaded from a thread w/ an
<          * applet on the stack, and then it can't read
<          * it's own content-types.properties file.
<          */
<         try {
<             DeployPerfUtil.put("START - Java   - ENV - " +
< 			       "AppletViewer.initEnvironment - prep MIME types table");
<             sun.net.www.MimeTable mt =
<             sun.net.www.MimeTable.getDefaultTable();
<             DeployPerfUtil.put("END   - Java   - ENV - " + 
< 			       "AppletViewer.initEnvironment - prep MIME types table");
<         } catch (Throwable e) {
<             Trace.printException(e);
<         }
<      

diff Applet2Environment.javaORIG Applet2Environment.java
426,438d425
<             /* we reference this class to get it loaded
<              * from a class w/o a classloader.  If not,
<              * it first gets loaded from a thread w/ an
<              * applet on the stack, and then it can't read
<              * it's own content-types.properties file.
<              */
<             try {
<                 sun.net.www.MimeTable mt =
<                     sun.net.www.MimeTable.getDefaultTable();
<             } catch (Throwable e) {
<                 Trace.printException(e);
<             }
<
                                     

EVALUATION

Invoking MimeTable.getDefaultTable in an unprivileged context should NOT be a problem. getDefaultTable executes its actual body in a privileged block, so not problem reading content-types.properties off the local file system.

What if plugin is run with a previous JRE? Well, getDefaultTable has been executing its method body in a privileged block since JDK 1.2 beta. So removing the call to getDefaultTable completely from the deployment code should be fine ( unless of course the user tries to run the latest plugin with a JDK1.1 JRE! )

I've tested this, i.e. removing the invocation of getDefaultTable from the deployment code and then executing an applet that will trigger the loading of the mime table through URLConnection.getFileNameMap. It works fine, no permission issues.