In hindsight that makes perfect sense and answers my question. If it was
vitally important to enforce this (it isn't, but hypothetically) I guess I
could mess with the catalina.policy file.
--Pete
"Bill Barker"
<wbar...@wilshire
.com> To
Sent by: news users@tomcat.apache.org
<n...@ger.gmane.o cc
rg>
Subject
Re: Tomcat 6 classloading and the
12/15/2008 11:32 Servlet 2.5 API spec
PM
Please respond to
"Tomcat Users
List"
<us...@tomcat.apa
che.org>
<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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
