[jcifs] More classloader issues

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Glass, Eric [SMTP:eric.glass at capitalone.com]
> 
> > > The problem will arise under Tomcat when NtlmFilter is 
> > loaded; it will find
> > > the implementation under the system classloader, but 
> > NtlmFilter will be
> > > unable to find javax.servlet.Filter (which is loaded under 
> > the common
> > > classloader).  This will cause a NoClassDefFoundError, specifically:
> > 
> > But the container will be trying to load classes in the Webapp class
> > loader. So when accessing jcifs.http.NtlmHttpFilter it will fail as it
> > will in the Shared and Common class loaders before 
> > successfully loading
> > from the System class loader. Now when resolving the 
> > javax.servlet.Filter
> > baseclass and other servlet classes will it try from the Webapp
> > classloader again or degenerate to the classloader from which it just
> > loaded jcifs.http.NtlmHttpFilter? I don't see the security risk in
> > starting from the original context loader again.
> 
> 
> It's not as much a matter of security as it is visibility; what happens is:
> 
	<snip>

> f) As part of the class definition process, the system classloader attempts
> to locate and load the superclass (javax.servlet.Filter).  This process is
> independent of the loading of NtlmHttpFilter; the system classloader is
> unaware of the existence of the descendant classloaders (common, shared, and
> webapp).  Since the system classloader is the defining classloader for
> 
	Ok. I didn't understand this. I thought (hoped) each class would be loaded using
	some kind of static "context" based on the initial class that would re-evaluate the
	hierarchy of classloaders.

> NtlmHttpFilter, that is where the search begins (and, as it turns out, ends
> with a failure).
> 
> This is kind of a simplification; in reality only the webapp classloader
> attempts to load the class before delegating to the parent (the normal JDK
> behavior is to delegate to the parent first, and load the class only if the
> parent cannot find it; the servlet spec reverses this behavior for the
> webapp classloader to allow web applications to override container-wide
> classes).  But the end result is the same; webapp fails, and delegates to
> shared, which delegates to common, which delegates to system, which
> succeeds.  While defining the NtlmHttpFilter class, system attempts to load
> javax.servlet.Filter, and fails.
> 
> Basically each classloader is only aware of its parent, and has no means of
> knowing if any child classloaders exist.
> 
> 
> > 
> > Also getting jcifs.smb.Handler installed in the System class loader is
> > a completely separate issue right? There's really no relation between
> > the problems other than their both being "class loading" issues.
> > 
> 
> 
> That is correct, with the caveat being that putting jcifs.smb.Handler in the
> system classloader also puts NtlmHttpFilter in the system classloader (since
> they are packaged together), which causes the Tomcat issue.  To resolve it,
> Tomcat users have to make sure that the core servlet classes are available
> in either the same classloader as jCIFS or an ancestor; this involves
> leaving jcifs.http.* under the webapp classloader (as a separate jar) or
> moving "servlet.jar" into the system classloader with the jCIFS jar.
> 
	<snip>

> > I just need to establish the simplest "correct" installation 
> > procedure. So
> > far, ensuring the jar is loaded by the System class loader 
> > and that it's
> > codeBase has the necesary PropertyPermission should work. If 
> > anyone wants
> > a more finely grained procedure they can be referred to these messages
> > in the archive.
> > 
> 
> 
> Possibly a note for Tomcat users to relocate the servlet.jar, or a note to
> see the FAQ.  Other than that, this should suffice.
> 
	Well we cannot just put the regular jar in the webapp WEB-INF/lib because of
	the PropertyPermission issue 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?