[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