-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin,
On 3/29/2010 7:56 PM, Konstantin Kolinko wrote: > 2010/3/25 Christopher Schultz <ch...@christopherschultz.net>: > > I will try to be brief in my answers below, so please excuse some > apparent harshness. > >> (...) >> 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. > > Why are you looking there? The policy file cited there is > "conf/catalina.policy". I would prefer the live copy over the paper. > (Though the doc should match the file). It does, but I've found it's better to give list readers something to click on instead of saying "hey, get the latest Tomcat tarball and look at the policy file included". I suppose I could have gotten the link from svnweb, but, well, that takes a while, too. >> 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. > > Java 6 docs are below from here: > http://java.sun.com/javase/6/docs/technotes/guides/security/index.html > > See also the following document there > http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc.html > http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-specTOC.fm.html I'll take a look at all of those. Thanks for the references. >> it appears that the SecurityManager is enforcing >> permissions along with the call chain... > > It is documented in those specifications by Sun. It looks the call > chain up to the nearest AccessController.doPrivileged(). My question was this: is the immediate caller before the AcessController.doPrivileged() the one checked, or is the /entire call chain/ checked recursively? The small amount of evidence I've collected leads me to that conclusion, and I'd like to be sure so that I can write policy files without completely losing my sanity. >> Third: doesn't this make performance really suck? > > As with any performance question: test it yourself and for your own > application/environment. Only that will give you numbers. Fair enough. > It may be that impact of those "security checks" is small compared to > other bottlenecks in one's application. Though, personally, I do not > like when a computer performs "useless" work. This is what I was getting at, though in my current position, it pays to have as many layers of (reasonable) security as possible. We do have control over all the code, but I'd also like to make sure that a rogue programmer/library or careless mistake doesn't really foul things up. >> such as granting AllPermission to things like bootstrap.jar > > That is determined by the task that this protection performs. > In general, the idea is that what is installed by "administrator" is > controlled and thus trusted, but the web applications themselves are > not trusted by default. This was my real question here: is the codebase-less grant and the granting of AllPermission just basically laziness on the part of the policy writer? Or is there a real reason to grant /all/ privileges to Tomcat. Here's what's in the policy file (I refer you to the catalina.policy file that ships with Tomcat 6.0.26 :) regarding the JDBC driver privileges: // The permission granted to your JDBC driver // grant codeBase "jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar!/-" { // permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect"; // }; That shows the codebase of the driver's JAR being given a SocketPermission. If my web application tried to create a JDBC connection directly (that is, by not using Tomcat's connection pool), would it fail? My experience with the logging framework suggests that it would fail. If I need to create a JDBC connection from within my webapp, do I have to do something like this: grant codeBase ".../my-jdbc.jar" { permission ... } grant codeBase ".../my-service.jar" { permission ...} grant codeBase "webapps/mywebapp/WEB-INF/classes/-" { permission ... } all with the same "permission" so that this will work? If I want to get really anal retentive, can I specify exactly which classes are allowed to make new JDBC connections by setting this SocketPermission for each one of them? That gives me great flexibility at the cost of a PITA when writing my policy file... which is why I suspect people just say "screw it" and do something like this: grant { permission SocketPermission "...", "resolve, connect"; } Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuyceAACgkQ9CaO5/Lv0PAsvACdFJPEZRrT3ghZ+PbSGCJR6CIO 1q0An2nRvylFW++7ZOOvyuJbENRAnh4C =gPID -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
