[jcifs] jcifs on J2EE compliant server

Eric eglass1 at attbi.com
Tue Dec 10 15:07:28 EST 2002


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) 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)
> 	at com.sun.web.server.J2EEInstanceListener.instanceEvent(J2EEInstanceListener.java:86)
> 	at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:262)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:228)
> 	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
> 	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:265)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
> 	at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
> 	at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
> 
> [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)
> 	at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:342)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
> 	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
> 	at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:101)
> 	at jcifs.http.TRLNtlmHttpFilter.doFilter(TRLNtlmHttpFilter.java:22)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
> 	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
> 	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValvejava:265)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
> 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
> 	at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
> 	at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
> 
> 
> Any suggestions or solutions?
> 
> NOTE: The same war file was deployed on a Tomcat 4.0 server and it runs without any problems. 
> 
> Regards,
> Lyn
> 


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.

Eric





More information about the jcifs mailing list