Placing a gbean and/or EJB in a signed jar causes a SecurityException during
deployment and/or runtime
------------------------------------------------------------------------------------------------------
Key: GERONIMO-2856
URL: https://issues.apache.org/jira/browse/GERONIMO-2856
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 1.1.1
Environment: Geronimo version 1.1.1. I don't believe the OS and
hardware are relevant, but this is running under Windows (both XP and server
have been tried)
Reporter: Yoel Spotts
Priority: Minor
The issue surrounds Geronimo's usage of proxies and how it relates to signed
jars. Thus far, I have encountered two issues in this regard:
a) If an EJB is deployed as part of an ear, and the EJB classes are contained
in a signed jar within the EAR, the EAR will fail to deploy at all (I have
tried to deploy offline, but I doubt deploying online would make a difference).
I hope to attach a sample of this (named example-full.ear) which highlights
this issue. You will note the EJB classes are located in the signed jar
example.jar and the ejb's manifest places example.jar in the classpath, so that
the classes are found, but the proxies created for the EJB classes are located
out of the signed package, just causing the SecurityException.
b) If a Gbean loaded by an EAR (defined in geronimo-application.xml) is placed
in a signed jar in the EAR, the EAR will be deployed, but will fail to startup,
due to a SecurityException, again b/c of the proxy class created for the gbean.
I hope to attach an ear highlighting this issue (named example-partial.ear).
Again, the signed example.jar contains a gbean (and again, the ejb's manifest
places the example.jar on the classpath)
Besides the obvious solution of not signing the jar, it was suggested to try
the experimental property: -DXorg.apache.geronimo.gbean.NoProxy=true. I did try
that, and it does seem to solve manifestation b) of this issue. However, it
won't address part a) above and is still experimental; It does not seem clear
what functionality is lost by using this option.
A possible resolution might be to create the proxies in a different package
than the target classes, which might not cause a SecurityException in that
case. Another possible avenue came from Dain Sundstrom on the mailing list:
"Alternatively, just change the code that complains about the signature. We
could add a flag to the Geronimo class loader to hide all signing data."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
