axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: J2EE Security permission for J2EE 1.3 and Axis
Date Tue, 26 Mar 2002 18:05:43 GMT
Just an FYI - when you talk about some of this being an issue for the
client - its not just a client issue - these problem appear on the server
when you place handlers in the server side chains and they do some
of the stuff that is typically considered client-side behavior.  For
example,
I wanted to use the "local" transport on the server side a little while ago
and ran into problems because that TRANSPORT_PROPERTY system
property wasn't getting set - no matter how I tried to set it, it never
stuck.
I ended up having to do what you talked about which is writing my own
URLStreamHandler (or something like that).  It was really ugly.  And
then of course I had a problem because trying to get the local transport's
Axis Server to use the proper server-config.wsdd file in all of the web
servers I wanted to run in was a real PITA.
-Dug


Greg Truty/Austin/IBM@IBMUS on 03/26/2002 12:53:49 PM

Please respond to axis-dev@xml.apache.org

To:    axis-dev@xml.apache.org
cc:
Subject:    J2EE Security permission for J2EE 1.3 and Axis



Hi,

Just to start making people aware of this issue, J2EE 1.3 introduces a set
of security permissions that require enforcement by J2EE vendors.  I have
noticed that we have code within Axis that get's affected by this new
requirement.  Specifically, there are 2 places that I have found so far:

1) org.apache.axis.client.Call
2) org.apache.axis.MessageContext

Call.java

The failure on Call.java is due to the System.setProperty() call for
TRANSPORT_PROPERTY.  This is being done in Axis to allow custom URL
handlers.  Since this is run in client applications, each application would
have to enable writing of this property (or the entire app-server's VM
would have to change)... but this would violate the J2EE spec.  The JDK
does provide a mechanism for not using the java.protocol.handler.pkgs
System property, by defining your own URLStreamHandlerFactory.  However,
this too requires authority to set it: (permission java.net.NetPermission
"specifyStreamHandler";).

It's probably a bad thing to allow system properties to be set by our
client code anyway...  Therefore, I'm leaning towards suggesting some other
mechanism for runtime initialization and removing it out of the mainstream
path for all client usages.

MessageContext.java

The failure on MessageContext is in a static initializer (on first load of
the class) which deletes/creates the attachments directory.  The JDK only
allows read/write of FilePermission, not create/delete.

It's probably a bad thing to create this dynamically (and should be
something done by the appserver or even SimpleAxisServer vs. some static
initializer in MessageContext.

I don't have fixes/patches for this yet... but thought I would at least
bring this to the attention of folks to (a) avoid further issues w/Java2
Security and (b) allow folks to fix this for me...  :-).

Regards...Greg




Mime
View raw message