[jcifs] More classloader issues

[Michael B. Allen]

On Mon, 16 Dec 2002 05:47:16 -0500
"Glass, Eric" <eric.glass at capitalone.com> wrote:

> > 	Well we cannot just put the regular jar in the webapp 
> > WEB-INF/lib because of
> > 	the PropertyPermission issue
> 
> Actually, the PropertyPermission issue is a fairly minor one; most
> containers (standalone Tomcat included) don't enforce any security policy
> unless explicitly told to.  The issue preventing the jCIFS jar from residing
> in the WEB-INF/lib directory is the need for the URL class to load
> jcifs.smb.Handler from the system classloader.

Well, I was suggesting that we place instruct users to place the regular
jCIFS jar in both the container CLASSPATH *and* in the WEB-INF/lib
directory. Just based on what you have been saying this would work with
the exception that it will trigger the PropertyPermission issue. So by
placing the normal jCIFS jar (meaning not splitting it up) it sould work
provided the container (i.e. generic Tomcat) does not install a policy
that restricts PropertyPermission.

> > but perhaps, just for Tomcat users, we can just
> > 	create an extra "jcifstomcat.jar" that has just the 
> > jcifs.http package for putting
> > 	in WEB-INF/lib directory of the web app. The regular 
> > jar would be left alone and
> > 	will also contain the jcifs.http package. Does that 
> > sound feasable?
> > 
> 
> I actually attempted this earlier; now you get into a semantically sticky

Yeah, but didn't you completely split the jar in two? I think there is
a slight advantage to leaving one of the jar with everything so that
users other than Tomcat and it's derivatives are not required to install
2 jars just because of Tomcat.

> area.  According to the servlet spec:
> 
> "It is recommended also that the application class loader be implemented so
> that classes and resources packaged within the WAR are loaded in preference
> to classes and resources residing in container-wide library JARs."
> 
> This is satisfied in Tomcat by loading classes from the web application
> classloader before attempting to load from the shared or common
> classloaders.  However, the spec also states:
> 
> "It must not allow the WAR to override J2SE or Java servlet API classes."
> 
> Tomcat satisfies this requirement as follows (from
> org.apache.catalina.loader.WebappClassLoader):
> 
> 
> // (0.2) Try loading the class with the system class loader, to prevent
> //       the webapp from overriding J2SE classes
> try {
>     clazz = system.loadClass(name);
>     if (clazz != null) {
>         if (resolve)
>             resolveClass(clazz);
>         return (clazz);
>     }
> } catch (ClassNotFoundException e) {
>     // Ignore
> }
> 
> 
> So if jcifs.http.NtlmFilter is placed in both the system AND webapp class
> paths, it will be loaded by the system classloader (somewhat
> counterintuitively, and contradictory to Tomcat's documentation on
> classloading at
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html).
> I'm not sure if this is technically a bug, in that this implementation does
> satisfy the spec -- J2SE and Servlet API classes cannot be overridden by web
> applications.  It just doesn't work in our case because the servlet API
> classes aren't visible to the system classloader.

I don't understand. If someone rolls the jcifstomcat.jar with
the jcifs.http package in it into their WAR file and put the
jcifs-x.x.x.jar file in their container CLASSPATH then .... ? I think
it will work based on what you just said. Presumably they would not put
javax.servlet.HttpFilter in the WAR file and even if they did it is a
Java servlet API class. What is in danger of being loaded inappropriately
in this case?

> 
> Eric
>  
> **************************************************************************
> The information transmitted herewith is sensitive information intended only
> for use by the individual or entity to which it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.


-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.