3

I mentioned a small demo. in Setting up policies for an Applet embedded in HTML & an Iced Tea JRE user commented that the demo. failed for them. They refused permission to the applet (thereby limiting it to the sand-box) & were supposed to see the green colored 'this applet is sand-boxed' page. Instead the applet completely failed and they saw a 'gray space' where the applet should have been.

I am WAGing that it was attempting to instantiate a File object that is the difference. I.E. The Sun/Oracle JRE will allow it without problem, only throwing a security exception when the applet attempts to create the JFileChooser. OTOH the Iced Tea JRE does not allow the File to be created.

As such, this code should fix that problem. It moves the creation/adding of the JEditorPane and installation of 1st an 'all else fails' message, then the green colored 'sand-boxed' page, to before the new File(..) call.

My question is. Does this code 'work as advertised' for users with an Iced Tea JRE?

To test it:

  1. Visit the applet at pscode.org/test/docload/applet-latest.html
  2. Refuse the digitally signed code. This is very important to create the right conditions to test the applet.
  3. Observe/report whether the applet loads the green colored sandbox.html. The sand-boxed document will represent 'success' at fixing the bug.

Also of interest (what little there might be) is the homepage for the Demo of Defensive Loading of Trusted Applets, which links to the applet page(s), each of the HTML files displayed in the applet, and a ZIP archive containing the source of the code & HTML, and an Ant build.xml so you can 'do this at home, kids'.

Here is the new code.

package org.pscode.eg.docload;

import java.awt.BorderLayout;

import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;

import javax.swing.JApplet;
import javax.swing.JButton;
import javax.swing.JEditorPane;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JFileChooser;

import java.net.URL;
import java.net.MalformedURLException;

import java.io.File;
import java.io.IOException;

import java.security.AccessControlException;

/** An applet to display documents that are JEditorPane compatible.
This applet loads in a defensive way in terms of the security environment,
in case the user has refused to accept the digitally signed code. */
public class DocumentLoader extends JApplet {
    JEditorPane document;

    @Override
    public void init() {
        System.out.println("init()");

        JPanel main = new JPanel();
        main.setLayout( new BorderLayout() );
        getContentPane().add(main);

        document = new JEditorPane("text/html",
            "<html><body><h1>Testing</h1><p>Testing security environment..");
        main.add( new JScrollPane(document), BorderLayout.CENTER );
        System.out.println("init(): entering 'try'");

        try {
            // set up the green 'sandboxed URL', as a precaution..
            URL sandboxed = new URL(getDocumentBase(), "sandbox.html");
            document.setPage( sandboxed );

            // It might seem odd that a sandboxed applet can /instantiate/
            // a File object, but until it goes to do anything with it, the
            // JVM considers it 'OK'.  Until we go to do anything with a
            // 'File' object, it is really just a filename.
            System.out.println("init(): instantiate file");
            File f = new File(".");
            System.out.println("init(): file instantiated, create file chooser");
            // Everything above here is possible for a sandboxed applet

            // *test* if this applet is sandboxed
            final JFileChooser jfc =
                new JFileChooser(f); // invokes security check
            jfc.setFileSelectionMode(JFileChooser.FILES_ONLY);
            jfc.setMultiSelectionEnabled(false);

            System.out.println(
                "init(): file chooser created, " +
                "create/add 'Load Document' button");
            JButton button = new JButton("Load Document");
            button.addActionListener( new ActionListener(){
                    public void actionPerformed(ActionEvent ae) {
                        int result = jfc.showOpenDialog(
                            DocumentLoader.this);
                        if ( result==JFileChooser.APPROVE_OPTION ) {
                            File temp = jfc.getSelectedFile();
                            try {
                                URL page = temp.toURI().toURL();
                                document.setPage( page );
                            } catch(Exception e) {
                                e.printStackTrace();
                            }
                        }
                    }
                } );
            main.add( button, BorderLayout.SOUTH );

            // the applet is trusted, change to the red 'welcome page'
            URL trusted = new URL(getDocumentBase(), "trusted.html");
            document.setPage(trusted);
        } catch (MalformedURLException murle) {
            murle.printStackTrace();
            document.setText( murle.toString() );
        } catch (IOException ioe) {
            ioe.printStackTrace();
            document.setText( ioe.toString() );
        } catch (AccessControlException ace) {
            ace.printStackTrace();
            // document should already be showing sandbox.html
        }
    }

    @Override
    public void start() {
        System.out.println("start()");
    }

    @Override
    public void stop() {
        System.out.println("stop()");
    }

    @Override
    public void destroy() {
        System.out.println("destroy()");
    }
}
Community
  • 1
  • 1
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
  • In the AppletViewer both `applet.html` and `applet-latest.html` work without problems - showing green page, and not asking for any permissions. (They both show the AccessControlException stacktrace on the console.) – Paŭlo Ebermann Mar 18 '11 at 19:48
  • 1
    One more comment about your build file: `source="1.2"` does not work when using `@Override`, at least in my compiler+ant combination (Apache Ant version 1.7.1 compiled on July 5 2010, javac 1.6.0_20). – Paŭlo Ebermann Mar 18 '11 at 20:29
  • "source="1.2" does not work when using @Override" Oops! My apologies. The build file was specifying 1.5 throughout until moments before I uploaded it. I figured it was all 'basic Swing' so I adjusted it to 1.2. (But I am running the build file using Java 1.6, & Ant 1.8). – Andrew Thompson Mar 19 '11 at 04:02

2 Answers2

3

Here is the output on java.stderr (one half of the equivalent of the Java console - the other half is java.stdout, which is empty in your case):

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:604)
        at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
        ... 2 more
Caused by: 
net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
        at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
        at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
        at sun.applet.AppletPanel.run(AppletPanel.java:380)
        at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
        at sun.applet.AppletPanel.run(AppletPanel.java:430)
        at java.lang.Thread.run(Thread.java:636)
java.lang.Exception: Applet initialization timeout
        at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
        at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
        at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
java.lang.RuntimeException: Failed to handle message: handle 60822154 for instance 2
        at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:660)
        at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
        at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
Caused by: java.lang.Exception: Applet initialization timeout
        at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
        ... 2 more

So, it looks like your applet code is not even loaded if I press Cancel in the dialog box.

confirmation dialog

I think there is nothing you can do here from the Java side - maybe using another signing procedure or starting the applet by JNLP would help. Or filing a bug report on IcedTea.


To demonstrate this, I created a real simple applet by omitting everything critical from your applet:

package org.pscode.eg.docload;

import java.awt.FlowLayout;
import javax.swing.*;

public class Example extends JApplet {


    JLabel label;

    public void init()
    {
        System.out.println("init()");
        SwingUtilities.invokeLater(new Runnable(){public void run() {
            label = new JLabel("inited.");
            getContentPane().setLayout(new FlowLayout());
            getContentPane().add(label);
        }});
    }

    @Override
    public void start() {
        System.out.println("start()");
        label.setText("started.");
    }

    @Override
    public void stop() {
        System.out.println("stop()");
        label.setText("stopped.");
    }

    @Override
    public void destroy() {
        System.out.println("destroy()");
        label.setText("destroyed.");
    }
}

I compiled this and modified your HTML file to use this instead, and it gives totally the same symptoms.

It seems IcedTea has redefined what to do when the user presses cancel. To be fair, the buttons in the dialog box are "Run" and "Cancel", not "Run with all permissions" and "Run sandboxed".

(In Sun's dialog there are the same buttons, but in effect they mean something else than asked.)

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
  • "It seems IcedTea has redefined what to do when the user presses cancel. To be fair, the buttons in the dialog box are "Run" and "Cancel", not "Run with all permissions" and "Run sandboxed". True. Sometimes I let a default behavior lull me into a false sense of security about how other JREs *should* behave. It seems JS will need to be invoked in order to keep the IcedTea user (at least) informed of what is going wrong. :( Thanks for your further testing. – Andrew Thompson Mar 19 '11 at 03:57
  • 1
    Another possibility would be to not sign your applet and use the `javax.jnlp` functions (`FileOpenService` here) for local file access - then the user is asked in the moment the file is needed, not at start of the applet. (And you can react on the non-opening of the file.) These functions are enabled always on IcedTea, on Sun only when loading with `jnlp_href=...`, and never on current Mac plugins (for Safari) (this is the downside). – Paŭlo Ebermann Mar 19 '11 at 11:27
  • 1
    "These functions are enabled always on IcedTea, on Sun only when loading with jnlp_href=..., and never on current Mac plugins (for Safari) (this is the downside)." (sigh) I've gotten so used to APIs (e.g. JMF Performance Pack, SaverBeans) or other Java related things not working on the Mac. that I (reluctantly) gave up on Mac. support some time ago. What I'm battling with now is that I cannot successfully create an applet that will use the JNLP services if available, yet fall back gracefully to a non-JNLP enabled solution for pre Plug-In 2 architectures! – Andrew Thompson Mar 19 '11 at 19:11
  • Has this been reported to the icedtea makers? If so, please attach a bug report address so the status of this issue can be followed. – rwst Aug 13 '12 at 07:51
1

For reference, I can confirm @Paŭlo Ebermann's results using IcedTea 1.9.7 on Ubuntu 10.04:

$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1~10.04.1)
OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)

appletviewer shows the expected sandbox and the fllowing diagnostic output. Firefox on Ubuntu offers only Run (trusted) or Cancel (nothing).

$ appletviewer http://pscode.org/test/docload/applet-latest.html
Warning: Can't read AppletViewer properties file: … Using defaults.
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
    at java.security.AccessController.checkPermission(AccessController.java:553)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
    at java.lang.System.getProperty(System.java:669)
    at javax.swing.filechooser.FileSystemView.getHomeDirectory(FileSystemView.java:397)
    at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:282)
    at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:153)
    at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:155)
    at javax.swing.JComponent.setUI(JComponent.java:651)
    at javax.swing.JFileChooser.updateUI(JFileChooser.java:1781)
    at javax.swing.JFileChooser.setup(JFileChooser.java:374)
    at javax.swing.JFileChooser.(JFileChooser.java:347)
    at javax.swing.JFileChooser.(JFileChooser.java:330)
    at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
    at sun.applet.AppletPanel.run(AppletPanel.java:436)
    at java.lang.Thread.run(Thread.java:636)
start()
stop()
destroy()

On Mac OS X, Safari 5.05 produces the expected results; and appletviewer produces comparable, but not identical, output.

$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-9M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)

$ appletviewer http://pscode.org/test/docload/applet-latest.html
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.io.FilePermission . read)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
    at java.security.AccessController.checkPermission(AccessController.java:546)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
    at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
    at java.io.File.exists(File.java:731)
    at javax.swing.JFileChooser.setCurrentDirectory(JFileChooser.java:548)
    at javax.swing.JFileChooser.(JFileChooser.java:334)
    at javax.swing.JFileChooser.(JFileChooser.java:316)
    at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
    at sun.applet.AppletPanel.run(AppletPanel.java:424)
    at java.lang.Thread.run(Thread.java:680)
start()
stop()
destroy()
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • Sorry, I overlooked this earlier. – trashgod Apr 22 '11 at 08:25
  • Thanks for your report, always welcome. I must get back to the Defensive Loading of Trusted Applets page and update it to (try to) account for this alternate behavior. The easiest way might be to use JavaScript to test for the applet appearing at all. – Andrew Thompson Apr 22 '11 at 08:51