Hash: SHA1


This is off-topic in that it doesn't really have anything to do
specifically with Tomcat, but I would be willing to bet that readers
would be interested in the answer. Besides, the pool of brain cells
available to this list is rather deep and I'd love an explanation of

I recently tried to set up Tomcat 6.x running under a SecurityManager.
As I fell down the rabbit hole, I saw that lots of things needed to be
granted to my code, which all makes sense in general. What I don't quite
get is the hierarchy of checks that are done.

In the Tomcat SecurityManager docs
most of the "grants" in the policy file do not have a codeBase. Some of
them do, such as granting AllPermission to things like bootstrap.jar,
which presumably means that any class in bootstrap.jar can do anything
it wants.

By the way, I /have/ read
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html but
some things are still unclear.

Since I didn't feel like granting permission to, say, write to my
application log file, to the entire webapp, I chose to grant that
privilege only to my log4j.jar file and the classes therein:

grant codeBase "jar:file:@app-dir@/WEB-INF/lib/log4j-1.2.15.jar!/-" {
   permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
   permission java.util.PropertyPermission "log4j.*", "read";

(Don't worry about all that @app-dir@ junk: it points to the right place
eventually, and I didn't feel like replacing it with something plausible
for publication).

Anyhow, this would seem to work great, except that I also configure
commons-logging to use the log4j logger, and the commons-logging library
tries to initialize the log4j logger at some point, which throws
permission errors. Hmm. So, I tried adding this, too:

grant codeBase
"jar:file:@app-dir@/WEB-INF/lib/commons-logging-1.1.1.jar!/-" {
   permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
   permission java.util.PropertyPermission
"org.apache.commons.logging.*", "read";
   permission java.util.PropertyPermission "log4j.*", "read";

That seemed to get me further through the process but then my own
application code was failing because... guess what? My code wasn't
allowed to call code that /was/ allowed to write to log4j.log. :(

Okay, fine:

grant codeBase "file:@app-dir@/WEB-INF/classes/-" {
   permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
   permission java.util.PropertyPermission
"org.apache.commons.logging.*", "read";
   permission java.util.PropertyPermission "log4j.*", "read";

This seemed to make things happy again, as far as the log file was
concerned. There are other issues for me to deal with, but this example
is illustrative: it appears that the SecurityManager is enforcing
permissions along with the call chain, not just with the finest-grained
code being checked for its permissions.

First: do I have this right? The JVM makes sure that permissions are in
place for every class on the call stack when such permissions are
checked? I suppose that would make sense, because then you could say
"well, my JDBC driver does the actual connecting to the database, but I
certainly don't want some rogue code in my webapp to create such a
connection... only allow Tomcat to create connections on my behalf".

Second - as a corollary to the first - is this why most examples of
policy grants simply say "grant { whatever }" to allow all code running
in the JVM to have that permission? Because the alternative is so
onerous that nobody wants to do it? Well, I kinda want to do it, so I
just want to know what the rules are.

Third: doesn't this make performance really suck?

Anyone who could shed some light on my understanding would certainly be
appreciated. I'm happy to read any references posted as well.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to