[jcifs] Java 1.3 Required and Unknown Protocol SMB Exceptions with Certai n Servlet Containers

[Glass, Eric]

Tomcat actually doesn't enforce this; in fact, Tomcat launches by default
with no security manager installed -- you have to launch it with the
"-security" option to install a security manager and enforce a policy.  The
Sun One J2EE Application Server's servlet container is based on Tomcat, and
DOES install a security manager by default to enforce the security
constraints recommended in the J2EE platform spec.  In both cases, however,
policy files are provided to allow tuning of the policy enforced by the
JVM's security manager.  The specific (minimum) grant that is really needed
is:

	permission java.util.PropertyPermission
"java.protocol.handler.pkgs", "read, write";

In the current state, however, Config calls System.getProperties() to
retrieve the full system Properties object; this requires

	permission java.util.PropertyPermission "*", "read, write";

since you could potentially directly change ANY property by directly
modifying the Properties object returned.  The change to just calling
System.getProperty() and System.setProperty() in 0.7.0b10 should allow the
more restrictive security setting to function properly.  With the
catch-and-ignore change, you could also modify the startup command line used
by the application server to manually set the necessary property yourself:

	java -Djava.protocol.handler.pkgs=jcifs

This would allow you to run the application server using the out-of-the-box
security policy.

> 
> 	2) Some Servlet and J2EE containers are not compatible 
> with *any* version of
> 	jCIFS because the URL protocol handler design and 
> Container specifications
> 	both supplied by Sun et. al. fails to consider that a 
> protocol handler
> 	implementation will need to set a system property 
> (java.protocol.handler.pkgs)
> 	when the security policies of some containers forbid 
> this (Tomcat appears to
> 	be one).
> 
> 

I agree that Sun's protocol handler provider mechanism is somewhat flawed;
most of the other provider-based APIs (XML parser providers, JCE providers,
etc.) have a more easily extensible installation mechanism.  Requiring
modifications to the system properties is cumbersome, because it requires
the end user to consciously "trigger" the installation; i.e., I either have
to launch the VM specifying "-Djava.protocol.handler.pkgs=xxxx" or ensure
that my code sets the property, i.e.:

System.setProperty("java.protocol.handler.pkgs", "xxxx");
URL mine = new URL("foo://host");

or in the case of jCIFS, triggering a load of the Config class before
attempting to create an SMB URL.  Either way, it "breaks" a major selling
point of pluggable protocol providers -- transparency to the end user.
Ideally, I would be able to drop the jCIFS jar in my classpath and be up and
running with no modification to my application code whatsoever.
Unfortunately, I don't think there's too much we can do to address this
issue, as it is Sun's design decision.

Eric




 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.