-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All,
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 policies. 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 (http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html), 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. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkurwYAACgkQ9CaO5/Lv0PD/DQCeMB+W7fvLhJeyWRdV6+uifI/w 3/8AoMJx1BWYeGnhCl5OZNGjrmraagja =SF0w -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
