[jcifs] jcifs on J2EE compliant server

Allen, Michael B (RSCH) Michael_B_Allen at ml.com
Tue Dec 10 16:15:47 EST 2002


> -----Original Message-----
> From:	Eric [SMTP:eglass1 at attbi.com]
> Sent:	Monday, December 09, 2002 11:07 PM
> To:	Tieu, Kiet L
> Cc:	jcifs at lists.samba.org
> Subject:	Re: [jcifs] jcifs on J2EE compliant server
> 
> Tieu, Kiet L wrote:
> > Hi,
> > 
> > SHORT:
> > Has anyone attempted to use jcifs successfully on a J2EE 1.3 compliant server?
> > Is jcifs J2EE 1.3 compliant?
> > 
> > 
> 
> SHORT: Strictly speaking, not currently.
> 
> 
> > LONG:
> > We attempted to implement the jcifs filter (NtlmHttpFilter) on Sun One Application Server V7, but encountered several problems.
> > 
> > Firstly, we noticed during initialisation the jcifs.Config attempts to get the system properties via System.getProperties(). However, the J2EE 1.3 spec disallows this. Following is the stack
> trace.
> > 
> 
> LONG: This is somewhat correct -- the spec actually states:
> 
> 
> "The exact set of security permissions for application components in use 
> at a particular installation is a matter of policy outside the scope of 
> this specification.  Some J2EE products will allow the set of 
> permissions available to a component to be configurable, providing some 
> components with more or fewer permissions than those described here. A 
> future version of this specification will allow these security 
> requirements to be specified in the deployment descriptor for 
> application components. At the present time, application components that 
> need permissions not in this minimal set should describe their 
> requirements in their documentation."
> 
> 
> You are correct in that the minimum security requirements enumerated by 
> the spec do not include "write" on java.util.PropertyPermission (which 
> is required by System.getProperties).  For compliance, the static init 
> block of jcifs.Config should probably be changed to do something like:
> 
> 
> 
> String ver = System.getProperty( "java.version" );
> if( ver.startsWith( "1.1." ) || ver.startsWith( "1.2." )) {
>      System.err.println( "jcifs-0.7.0b4+ requires Java 1.3 or above. You 
> are running " + ver );
> }
> String pkgs = System.getProperty( "java.protocol.handler.pkgs" );
> if( pkgs == null ) {
>      pkgs = "jcifs";
> } else {
>      pkgs += "|jcifs";
> }
> try {
>      System.setProperty( "java.protocol.handler.pkgs", pkgs );
> } catch (SecurityException ex) { }
> try {
>      filename = System.getProperty( "jcifs.properties" );
>      if( filename != null && filename.length() > 1 ) {
>          in = new FileInputStream( filename );
>      }
>      jcifs.util.Config.load( in );
> } catch( IOException ioe ) {
>      ioe.printStackTrace();
> }
> 
> 
> System.getProperty() only requires read access, so should be successful 
> under the default J2EE security policy.  The setProperty call above will 
> fail, however; if you need to use SMB URLs (if you're just using 
> NtlmFilter for simple NTLM HTTP authentication you probably don't)
> 
	SMB URLs are used internally by SmbFile although it's just possibly that
	the above code might permit NtlmHttpFilter to work. I have made the changes.

>  then 
> you would have to manually set the "java.protocol.handler.pkgs" property 
> yourself (probably by passing "-Djava.protocol.handler.pkgs=jcifs" to 
> the command line used to start the JVM or using whatever means your 
> application server provides to configure the environment properties).
> 
> 
> 
> > 
> > Reluctantly, we got around this by modifying the server.policy file from 
> > 	permission java.util.PropertyPermission "*", "read";
> > to
> > 	permission java.util.PropertyPermission "*", "read, write";
> > 
> > 
> > With this modification, the filter initialises without any errors. However, when we try access a "protected" page now, we are presented with the following error:
> > 
> > [10/Dec/2002:12:20:18] SEVERE ( 1288): WEB5003: Exception in handleAfterEvent.
> > com.sun.enterprise.InvocationException
> > 	at com.sun.enterprise.util.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:159)
> > 	at com.sun.web.server.J2EEInstanceListener.handleAfterEvent(J2EEInstanceListener.java:201)
	...
> > 
> > [10/Dec/2002:12:20:18] SEVERE ( 1288): StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
> > java.lang.ClassCastException: jcifs.smb.NtlmPasswordAuthentication
> > 	at com.sun.web.server.J2EEInstanceListener.handleBeforeEvent(J2EEInstanceListener.java:142)
> > 	at com.sun.web.server.J2EEInstanceListener.instanceEvent(J2EEInstanceListener.java:80)
	...


> This is fairly interesting... one of the internal Sun One classes is 
> apparently attempting to cast the NtlmPasswordAuthentication object to 
> something it does not implement.  Since it couldn't conceivably have any 
> knowledge regarding the internal jCIFS classes, my only guess would be 
> that it is attempting to serialize the objects in the HttpSession (and 
> is casting the NtlmPasswordAuthentication object to 
> java.io.Serializable).  This would require more investigation to 
> confirm, however.  If this turns out to be the case, 
> NtlmPasswordAuthentication could be made to implement Serializable 
> fairly easily; in fact, you could just add it to the implements class 
> and recompile the jCIFS classes if you wanted to test this out.
> 
	I don't see how this would work. The ansiHash and unicodeHash are
	specific to a particular SmbTransport. If an NtlmPasswordAuthentication
	object is marshalled into another/new VM using some form of serialization
	the hashes will be wrong. Or is this not what the container is trying to do?







More information about the jcifs mailing list