[jcifs] 1.3.x filter authentication problem

[Michael B Allen]

On Mon, Feb 9, 2009 at 11:36 AM, Caldarale, Charles R
<Chuck.Caldarale at unisys.com> wrote:
>> Subject: RE: [jcifs] 1.3.x filter authentication problem
>
> (Sorry for the previous message - fumble fingers on the keyboard.)
>
>> How does one create two instances of Jcifs, with different
>> configurations, within one VM?
>
> You will need a separate classloader for each instance of jCIFS.  If you're running inside Tomcat, each webapp uses a separate classloader already; just put the jCIFS jar in the WEB-INF/lib directory of each webapp.  Do not put the jar in Tomcat's shared directory.

Note that doesn't really help with the static properties issue since
the only way to set some properties reliably is with through
commandline using -Djcifs.properties=file.prp.

Just like the Windows CIFS client and smbclient, the configuration in
JCIFS is global and static. For example, on Windows the
LmCompatibilityLevel is in the registry and extended security is
basically hard coded into the client. These are not things that can be
changed at runtime. Meaning they're global and static.

The heart of the problem in this thread is that servlet containers set
things at runtime using init-params but the Filter doesn't support
NTLMv2 so the new 1.3 default values of
jcifs.smb.client.useExtendedSecurity=true and
jcifs.smb.lmCompatibility=3 are wrong for the Filter. Strangely I
would think this should still work since the properties aren't
actually set the JCIFS classes are first loaded. But it looks like
Tomcat at least is maybe loading some JCIFS classes before it actually
reads the init-params so some init-params are basically ignored.

Fortunately this issue is largely specific to the combination of the
Filter not supporting NTLMv2 and how some servlet containers load
classes. So none of this really matters much since the Filter is
effectively deprecated.

But it doesn't mean that we can't make the JCIFS configuration more
flexible in the future. It would be nice to be able to supply
different configurations. But if the config is not global and static
the issue is "where do you put it?". My thought is that we can hang it
on the current thread or stick it in the JAAS Subject so that it get's
inherited (are Subjects inherited when creating new Threads?). But of
course that's a fairly radical change and requires touching code in
many places so it is not going to happen soon.

Note that some people have suggested that this could be "fixed" by
simply making the properties non-static. That would not be
thread-safe. Meaning thread 1 could set property a, then thread 2
could set property a and then thread 1 could act on property a with
the wrong value and get the wrong result or a mysterious error.

In hindsight I should have removed the Filter in 1.3 so that people
would be forced to use 1.2 which has exactly the same Filter code with
the right default values for useExtendedSecurity and lmCompatibility.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/