Hi guys,
Our application uses Axis2 v1.5. We want to using our application with
enabled security manager on web server (Web Sphere v7.0) without next
permissions:
- createClassLoader issue
- temp folder issue
- setContextClassLoader issue
- was.install.root issue
Currently those permissions should be removed from was.policy file.
grant codeBase "file:application.war" {
permission java.io.FilePermission
"${user.install.root}${/}temp${/}-", "read, write, delete";
permission java.io.FilePermission "${java.io.tmpdir}", "read,
write, delete";
permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read,
write, delete";
permission java.io.FilePermission "${was.install.root}${/}-","read";
permission java.lang.RuntimePermission "createClassLoader";
permission java.lang.RuntimePermission "setContextClassLoader";
permission com.ibm.oti.shared.SharedClassPermission
"org.apache.axis2.deployment.DeploymentClassLoader", "read, write";
};
So, we got the source code -
http://archive.apache.org/dist/ws/axis2/1_5/axis2-1.5-src.zip and made
the changes to fix that issues.
Could you please review our changes and commit it to you trunk or
working branch? Certainly if those changes will possible for new
releases.
So, how we fixed it:
* createClassLoader issue
- Utils.createDeploymentClassLoader() changed and renamed to
createInstanceClassLoader. Now it return class loader of type
ClassLoader instead of DeploymentClassLoader
- Public static ClassLoader.getClassLoader(ClassLoader arg1,
String arg2) changed. Now it uses ClassLoader.newInstance() method
instead of constructor to create class loaders.
- DeploymentClassLoader removed completely because it used
to load classes from aar and mar files. We unpacked these archives so
we don=92t need special class loader. We use ClassLoader instead.
All changes mentioned above works correctly since we have all modules
and services classes on classpath, because structure of our
application has been reorganized.
The next classes were changed (see diff file below):
org.apache.axis2.deployment.DeploymentClassLoader
org.apache.axis2.deployment.DeploymentEngine
org.apache.axis2.deployment.util.Utils
* temp folder issue
Application will not halt when temp folder is unreachable for
WarBasedAxisConfigurator (package org.apache.axis2.deployment). Also
we=92ve added check if temp folder is reachable for
org.apache.axis2.deployment.util.TempFileManager. In case the folder
is unreachable, this class will skip all operations with it.
We=92ve found that class org.apache.axis2.context.ConfigurationContext
in Axis2 had tried to clean temp folder. We used the same approach as
in TempFileManager manager to fix it.
The next classes were changed (see diff file below):
org.apache.axis2.deployment.util.Utils
org.apache.axis2.context.ConfigurationContext
org.apache.axis2.deployment.util.TempFileManager
org.apache.axis2.deployment.WarBasedAxisConfigurator
* was.install.root folder access issue
Axis2 has searched some jars in "was.install.root" folder and has
tried to read it. We can suggest that it have searched some modules or
services there. We applied fix to prevent Axis2 fault if it has no
permission to read files in "was.install.root" folder.
The next classes were changed (see diff file below):
org.apache.axis2.deployment.RepositoryListener
org.apache.axis2.util.Utils
* setContextClassLoader issue
Number of classes in Axis2 has workflow which brakes
setContextClassLoader permission.
Our application uses two classes (AbstractMessageReceiver and JAXWSDeployer=
).
All of them have same behavior. Here is brief description:
ClassLoader threadClassLoader =3D null;
try {
threadClassLoader =3D Thread.currentThread().getContextClassLoader();
operation();//here classloader might change
} catch (Exception e) {
log.info(Messages.getMessage("deployingexception", e.getMessage()), e);
try {
if (threadClassLoader !=3D null) {
log.info("We are in old finally block");
SecurityManager security =3D System.getSecurityManager();
if (security !=3D null) {
security.checkPermission(new RuntimePermission("setContextClassLoader"));
}
Thread.currentThread().setContextClassLoader(threadClassLoader);
}
} catch (SecurityException e) {
log.info("We have security restriction on setContextClassLoader");
}
operation() never change classloader if we have security permission.
So if we have no security restrictions on setContextClassLoader, the
behavior of application won=92t be change. And in case if we have no
permission to change context classloader, application will work
propertly but also will notify about restriction.
The next classes were changed (see diff file below):
org.apache.axis2.jaxws.framework.JAXWSDeployer
org.apache.axis2.receivers.AbstractMessageReceiver
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org
