[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