Anigozanthos

I was poking around the TiddlyWiki Trac site and noticed a new ticket #253 opened on my Java saving code.

Apparently one or more of Gentoo Linux, the Linux JVM, or Opera for Linux require the saving code (and probably the loading code too) to be wrapping in a PrivilegedAction class into order to execute, regardless of Java security policy settings.

The ticket included some code, but sorry "thomaskammeyer", I don't like your style!

Here's my new Java code:

import java.io.*;
import java.security.*;

public class TiddlySaver extends java.applet.Applet {
  class PrivilegedLoad implements PrivilegedAction {
    private String filename;
    private String charset;

    public PrivilegedLoad(String filename, String charset) {
      this.filename = filename;
      this.charset  = charset;
    }

    public Object run() {
      try {
        if (charset.length() == 0) {
          StringBuffer data = new StringBuffer();
          BufferedReader r = new BufferedReader(new FileReader(filename));
          String line;
          while ((line = r.readLine()) != null) data.append(line).append("\n");
          r.close();
          return data.toString();
        } else {
          File f = new File(filename);
          FileInputStream i = new FileInputStream(f);
          byte[] b = new byte[(f.length() > Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int)f.length()];
          int offset = 0;
          int num = 0;
          while (offset < b.length && (num = i.read(b, offset, b.length - offset)) >= 0) {
            offset += num;
          }
          i.close();
          return new String(b, 0, offset, charset);
        }
      } catch (Exception x) {
        x.printStackTrace();
        return null;
      }
    }
  }

  class PrivilegedSave implements PrivilegedAction {
    private String filename;
    private String charset;
    private String data;

    public PrivilegedSave(String filename, String charset, String data) {
      this.filename = filename;
      this.charset  = charset;
      this.data     = data;
    }

    public Object run() {
      try {
        File f = new File(filename).getCanonicalFile();
        f.getParentFile().mkdirs();
        if (charset.length() == 0) {
          int e, s = 0;
          BufferedWriter w = new BufferedWriter(new FileWriter(f));
          do {
            e = data.indexOf('\n', s);
            if (e == -1) e = data.length();
            w.write(data, s, e - s);
            w.newLine();
            s = e + 1;
          } while (s < data.length());
          w.close();
          return Boolean.TRUE;
        } else {
          FileOutputStream o = new FileOutputStream(f);
          o.write(data.getBytes(charset));
          o.close();
          return Boolean.TRUE;
        }
      } catch (Exception x) {
        x.printStackTrace();
        return Boolean.FALSE;
      }
    }
  }

  public String loadFile(String filename, String charset) {
    return (String)AccessController.doPrivileged(new PrivilegedLoad(filename, charset));
  }
  public int saveFile(String filename, String charset, String data) {
    return ((Boolean)AccessController.doPrivileged(new PrivilegedSave(filename, charset, data))).booleanValue() ? 1 : 0;
  }
}

Here's the above compiled into a new JAR: TiddlySaver.jar
To Jeremy: If you're reading this, the build script needs a small change: The jar command needs to refer to all class files, i.e. "TiddlySaver*.class".

I've tested this on my WinXP machine using the standard policy and it worked fine, but could not test on MacOS or any flavour of Linux.

I've been experimenting with TiddlyWiki lately, including improved Opera support, and I've found something a little disquieting.

TiddlyWiki is basically a locally editable web page that implements a wiki. In order to be editable it must be able to read and write to a local file (itself) on your computer. Normally pages can't do that.

For IE, it uses an ActiveX object. By default, it's disabled and must be manually re-enabled the first time you load a local TiddlyWiki after starting the browser. I believe it's possible to always allow the ActiveX object access, but that would entail allowing every local web page (i.e. those in the My Computer zone) to read/write any local file. There is no way to say "only web pages in this folder may read/write files in that folder. Not very good. At least it's a hassle to figure out how to allow ActiveX access by default.

Firefox is similar. It requires giving TiddlyWiki UniversalXPConnect privileges. What's not immediately clear, though, is that saying by "yes", you're giving any "file:" web page those privileges - the ability to read/write any local file! What's worse is that Firefox has a helpful "remember this" checkbox, thereby making it trivial to allow your TiddlyWiki, and any other web page you might in the future save to your computer or a network share accessible to your computer, the ability to read/write any file they like. This is even worse than Internet Explorer, which distinguishes between files on your computer (the "My Computer" zone) and network shares (in the "Local Intranet" zone).

In theory, Firefox supports Per-File Permissions (note that that page indicates a pipe (|) character is required after the drive letter, it seems that's wrong and the character should be a colon (:)), thereby only allowing web pages in a specific folder the ability to read/write any file. In practice, I haven't been able to get it to work. Even if I could, I still consider it only a marginal improvement - allowing read/write access to any local file is rather scary!

Update: Thanks to a reader comment, I've been shown the error of my ways. Firefox's per-file permissions really are per-file! You have to specify the complete filename of the page to grant privileges to, a folder name (as is possible with Java policies) won't work. Each of your tiddlywikis (if you have more than one), will need to be separately granted permission.

Opera is different again. It has no built-in support to read/write files at all. To read/write local files, Opera must make use of Java. Even then, custom changes to the local user security policy are required, so it's not stupidly easy to grant these special privileges. Nor should it be. The best part is that Java allows files in only a specific folder to be granted specific privileges: in this case, the ability to read/write files in a specific folder. Files outside the specified folder are not granted extra privileges, and those that are inside it, can only read/write into the folder specified, not any files outside it.

Note that I'm talking about unsigned code. Signed code is given full access to your computer, but requires an expensive security certificate that must be regularly renewed. Even without that hassle, I still prefer the fine-grained control you get with unsigned code.

So, why not use Java for IE and Firefox? Sadly, it seems there's a bug in the Java plugin preventing the granting of privileges to web pages in a specific folder. Instead, you must grant the ability to read/write files in a folder to all local Java code. In technical terms, you cannot use the codeBase parameter in the grant policy statement. Opera isn't affected by this issue because it doesn't use the Java plugin, but accesses Java directly. I've made some enquiries into this bug, but so far I've had no responses.

In summary, only Opera supports the most secure arrangement: allowing only files in a specific folder access to files in another (or the same) specific folder. Without using Java, both IE and Firefox will allow any local file full access to any other local file (very scary). With Java, you can at least limit files that can be modified to a specific folder, even if you can't limit which files can do the modifying (not so scary).