views:

1619

answers:

1

We have a locally-developed triple store based on b-trees which I want to use for persistent storage in a number of servlet applications. Rather than embed the b-tree index files in the servlet .war, I would like to store them at a known location and have the servlets access them directly. This all works in Jetty, but raises a security exception when I try it in Tomcat. I'm told that Tomcat's security model requires explicit permissions for a servlet to access files outside the directory tree where the .war is unpacked. If I've understood the Tomcat (version 5.5) documentation correctly, the following added to catalina.policy should allow the servlet to access the directories where the index files are:

grant codeBase "jar:file:${catalina.home}/webapps/mytestapp/-"
{
  permission java.io.FilePermission "/var/data/tdb/-", "read, write, delete"; 
}

However, I still get a security exception:

java.io.FileNotFoundException: 
                    /var/data/tdb/kb/node2id.idn (Permission denied)
    at java.io.RandomAccessFile.open(Native Method)
    ...

To tick off the obvious dumb errors: I've checked that the index files are at the correct location, with the correct permissions, and are not corrupted. Any suggestions or hints at what I've got wrong in the security settings would be gratefully received.

+1  A: 
java.io.FileNotFoundException: 
                /var/data/tdb/kb/node2id.idn (Permission denied)

This is your OS denying access, not Java security. If it was Java security you would get an AccessControlException (or some other form of SecurityException). The user you are running the Tomcat process as presumably does not have access to that file.

Tom Hawtin - tackline
Hi Tom,Thanks for the info. That was my first thought, but I've already chown'ed and chgrp'ed the files, and directory they are in, to the same user and group as the Tomcat process. Still, it gives me a pointer to investigate. Thanks.
Ian Dickinson
Tom was right, it was an OS file permissions problem, not Tomcat. I haven't quite got to the bottom of it, but temporarily opening the file permissions on the test server to a+rw removes the exception. Now I just have to figure out a more restrictive setting that doesn't leave the store wide open!
Ian Dickinson