<peter_f...@blm.gov> wrote in message news:of14e2cc5d.7f3b739a-on87257520.0059a8c8-87257520.005b2...@blm.gov... > > I'm trying to clarify something about Tomcat 6 compliance to the Servlet > 2.5 spec. The spec (section 9.7.2) says: > > "The container should not allow applications to override or access the > container's implementation classes." > > In Tomcat 5 it looks like this was handled by having separate "common", > "shared" and "server" directories and the catalina.properties file > specified the classloader configuration such that application code > couldn't > get to the "server" classes and jars. In Tomcat 6, everything is rolled > into a single "lib" directory. The catalina.properties file can be > modified > to make things like the older Tomcat versions, but out of the box it looks > to me like an application could get to the catalina jar files. > > Going by a literal reading of the spec, Tomcat 6 is still technically > compliant (the spec says "should not", not "must not") but all the same it > seems a little strange that this was changed, unless there's something I'm > missing. Does Tomcat 6 have some other mechanism in place to make sure > that > applications can't access the container classes and worse, make changes to > the container's data at run time?
For a long time, the Tomcat developers realized that since Java provides introspection, there was really no additional protection provided by classloader segregation if you are not using a SecurityManager sandbox. As a result, they simplified the classloader structure by default and left it up to the admin to configure the sandbox as necessary. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
