views:

611

answers:

2

Has anyone managed to get BIRT to run under WebSphere with Java 2 Security switched on? Doesn't seem to matter what I put in my was.policy file, I get a huge number of security exceptions when I try to produce a report.

Running with Java 2 Security switched off works perfectly, but that's not an option for the production environment.

As an example : when my app runs I see the following in my stacktrace

Permission:

  * : Access denied (java.util.PropertyPermission * read,write)

 org.eclipse.osgi.framework.internal.core.FrameworkProperties  in  {file:/hosting/configs/WebSphereD03/AppServer/installedApps/CD03-crxaiuci5002/DOCGEN.ear/docgen.war/WEB-INF/platform/plugins/org.eclipse.osgi_3.3.1.R33x_v20070828.jar}

Stack Trace:

java.security.AccessControlException: Access denied (java.util.PropertyPermission * read,write)

Birt is packaged into my EAR file, so to get rid of this particular problem I have the following entry in my was.policy file

grant codeBase "file:${application}" {
permission java.util.PropertyPermission "*", "read,write";

};

That didn't seem to make any difference, so I tried

grant codeBase "file:/hosting/configs/WebSphereD03/AppServer/installedApps/CD03-crxaiuci5002/DOCGEN.ear/docgen.war/WEB-INF/platform/plugins/org.eclipse.osgi_3.3.1.R33x_v20070828.jar" {
permission java.util.PropertyPermission "*", "read,write";

};

Still no luck ...

Any one got any pointers?

Thanks

Dave

+1  A: 

Distinguish between WebSphere (JEE) security and Java 2 security

JEE security should be enabled for production applications (and WebSphere's admin too).

Java 2 Security actually buys very little, and isn't all that widely used in WebSphere land. It may be useful if intra-application isolation is very important, but in which case you have not solved the problem just by enabling Java 2 Security.

It's quite painful enabling Java 2 Security for the reason you indicate getting a useful set of permissions is tedious. a useful trick: set the System Property:

 com.ibm.websphere.java2secman.norethrow

this will cause all the permisions errors to be reported without the app failing. Hence you know the full set of permissions to grant.

djna
The problem I'm getting is that even when the I set norethrow and get a list of errors, adding the relevant permissions to my was.policy file does not seem to make the errors go away. I'll attempt to edit my inital posting to give examples
The problem only occurs with my BIRT application - I have a different application that does not use BIRT but appears to require similar permissions. Granting those permissions in was.policy makes the exceptions go away.
A: 

If anyone hits this problem again and cannot disable Java 2 security for any reason, I had exactly the same problem and posted on BIRT exchange forums. Jason Weathersby found a fix:

I suspect this issue has to do with OSGi writting into the web-inf/platform/configuration directory. Can you log a bug for this? You could try to modify the config.ini in web-inf/platform/configuration add an entry like: osgi.configuration.area=c:/birtconfigarea and make sure this directory is writeable. Jason

EDIT:

It turned out when testing this fix Java2 security hadn't properly been re-enabled, hence the above is not a fix. However I believe I have found a horrible fix:

Add the following to the config.ini file:

eclipse.security=null

Having had a look in the class OSGILauncher (org.eclipse.birt.core), there is a method setupSecurityPolicy() (line 700 v2.6.0) which looks for the property eclipse.security. If the property is null it goes ahead and sets up some OSGIPolicy, which seems to be the cause of the problem.

NOTE: This breaks a deployment in Tomcat, i.e. with the property eclipse.security set, the BIRT reporting platform fails to startup.

Ed