Hash: SHA1


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

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";

- -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