Tomcat permissions

As packaged with Ubuntu 8.04, Tomcat is set up pretty tight on security. The configured permissions are quite minimal, so many things you'd want to do in your servlets or JSPs needs to be explicitly permitted.

This isn't necessarily surprising; but it can be a pain.

First, some helpful links: The Security Manager HOW-TO in Apache's Tomcat documentation explains the basics. For specifics on the format of permission entries, see Sun's documentation on Default Policy Implementation and Policy File Syntax.

Notes:

• Tomcat's policy settings are (on my Ubuntu box) in /usr/share/tomcat5.5/conf/catalina.policy. But heed the warning in the file's header: If your system is Debian-esque (and that includes Ubuntu) then that file is auto-generated from a set of files in conf/policy.d, and those are the ones you want to be editing. Permissions you want to add for your web apps will likely best fit in 50user.policy.



• The policy files are concatenated and the settings initialized when Tomcat starts. Hence, you need to restart Tomcat in order for permission changes to have an effect.



• The codeBase string is a URL, so it always takes forward slashes. File names for FilePermission may be operating system dependent, so you should use ${file.separator} instead there.



• As explained in the Sun doc, an asterisk (*) in a path for FilePermission (roughly) means "everything in this directory", while a dash (-) means "everything in this directory and recursively in all subdirectories". Likewise, the beginning of a host address for SocketPermission may be wildcarded with an asterisk. In the extreme case, the entire host address may be an asterisk and so will apply to "any host".



• If you're having trouble getting permissions to take effect, you can try narrowing down the problem by making either the codeBase universal (surprisingly, the "codeBase" descriptor is optional, so it's quite legal to have a stanza that starts with "permit {" or the permission all-encompassing: that would be "java.security.AllPermission". Once you get stuff working with this gaping security hole, you will want to go back and try to tighten it up again.

Document is null

I tried to read an XML configuration file into a DOM, like so:

 InputStream configInputStream = this.getClass().getClassLoader().getResourceAsStream(CONF_FILE_NAME);
 log("configInputStream = " + configInputStream);
 DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
 DocumentBuilder db = dbf.newDocumentBuilder();
 Document doc = db.parse(configInputStream);
 log("Found and read configuration: " + doc);
 configInputStream.close();

...and the log said:
INFO: ToonGrator: Found and read configuration: [#document: null]

I guess the square brackets and the extra text should have tipped me off, but I sure thought
I had read in a null document!

It isn't really. It turns out that the root (or document) node always contains no text, so
whatever its toString() returns will say "null". Oh well, back to work!

Writing files from JavaScript

In Internet Explorer, you can use the ActiveXObject "microsoft.xmldom" to load an XML file into a DOM that can be inspected and manipulated from JavaScript. So far so good. But what if you want to write an XML file to the local file system? XmlDom has a save() method and the argument lets you specify a local file path. But in IE6 and later, the attempt will always fail.

The 'net is full of forum posts with frantic pleas for help with titles like "XML DOM save - File Permission denied". In almost all cases, the answers fell into the following categories:

"Tough luck, that's the way it is" / "the cookie crumbles."

True enough, but not helpful.

"You need to have write permission on the folder you're writing to!"

True enough, but I'll bet everyone with half a brain checked that before posting. Even if that was the problem, you'd run up against the previous one.

"I have the same problem. Please email me the answer!"

Me too!

"You can't do that from HTML, you need a HTA

True enough, but if the requester could get a user to download and execute an application he wouldn't have this problem in the first place.

"In ASP on the server you do this..."

That doesn't help with saving files on the client's file system.

It was a long time before I came across a post that mentioned FileSystemObject. It turns out that while xmldom.save() is never allowed to write to the local file system (apparently no amount of tweaking any permissions will change that), FileSystemObject can create, read, write and even delete files, subject to permissions given in IE's Internet Options.

It's no big deal to pull the XML from the DOM as a String and to save it using a TextStream object created by FileSystemObject.CreateTextFile(). Here's a code sample of mine that does it:

      function save2()
      {
       var xmlDoc = new ActiveXObject("microsoft.xmldom");
       xmlDoc.load(path + "stuff.xml");
       alert("stuff.xml loaded");
       fso = new ActiveXObject("Scripting.FileSystemObject");
       f2 = fso.CreateTextFile(path + "stuff2.xml", true);
       f2.write(xmlDoc.xml);
       f2.Close();
       alert("stuff2.xml saved");
      }

I surmise that more readers of those forums knew the "right" answer but chose not to tell because they suspected malicious intent on part of the requesters. When you can write to the user's file system you can do many evil things.

My take on this is: Any user surfing the Web with IE and permissions set to "trusting" is asking for trouble anyway; and the more professional malware authors already know how to exploit this. Microsoft's choice to never allow XmlDom to save looks silly in view of the fact that there's a perfectly workable back door.

My own use of this feature is legitimate, of course: I'm working with a JavaScript application that wants to store some user settings on the user's machine. More information than will fit into a cookie, and there's no server to persist the information on. Also, it's a closed environment, even to the user, with no Internet connection, so it can safely run with full permissions.