-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anyone?
On 3/25/2010 4:03 PM, Christopher Schultz wrote: > 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 - --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuws9AACgkQ9CaO5/Lv0PAOwQCgj7lfQLwbrtTjWZtnDi3wlgDD BHgAn27/t9LOKS3e/2oHRXYHOv3NcTvH =vE96 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
