[jcifs] 1.3.x filter authentication problem

[John.Baker at barclayscapital.com]

My question was unrelated to the filter - it was a general question
about configuration of jcifs.

I don't understand why there would be any threading issues with a
separate Properties object per instance of a jcifs object, unless there
are more statics lurking in the code.  

So, the answer is to be able to pass Properties objects into the
constructors of key objects (like SmbFile).  Or bind configurations to
Threads (less nice but entirely do-able). 

And then the HttpFilter can remain in Jcifs, and perhaps we can put some
work into new filters (for Kerberos, given they seem to be floating
around as ext packages).

> -----Original Message-----
> From: 
> jcifs-bounces+john.baker=barclayscapital.com at lists.samba.org 
> [mailto:jcifs-bounces+john.baker=barclayscapital.com at lists.sam
> ba.org] On Behalf Of Michael B Allen
> Sent: 09 February 2009 18:15
> To: Caldarale, Charles R
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] 1.3.x filter authentication problem
> 
> 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/
> 
_______________________________________________

This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing.  Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________