Affects: Release Notes project_key: JBEWS {code} startup.sh -security {code} Produces exceptions in log and tomcat do no start successfully -> see attachmets. The same scenario works fine on different platforms and different jdks
Attachment: Added: catalina.out
Link: Added: This issue relates to JBPAPP-9551
Release Notes Docs Status: Added: Documented as Known Issue Writer: Added: mhusnain
Release Notes Text: Added: When using JBoss Enterprise Web Server with Red Hat Enterprise Linux with either the IBM JDK 1.6 or 1.7, the startup.sh -security command does not start tomcat (6 or 7) as expected and produces exceptions in the logs.
Release Notes Docs Status: Removed: Documented as Known Issue Writer: Removed: mhusnain Release Notes Text: Removed: When using JBoss Enterprise Web Server with Red Hat Enterprise Linux with either the IBM JDK 1.6 or 1.7, the startup.sh -security command does not start tomcat (6 or 7) as expected and produces exceptions in the logs. Docs QE Status: Removed: NEW
it appears that adding permission java.lang.RuntimePermission \ "accessClassInPackage.org.apache.catalina.loader"; to catalina.policy would get past this instance, there might be others though. any chance of attaching the catalina.policy?
The forward slash is not part of the entry. it was added because the editor split the line.
Created attachment 745561 [details] catalina.policy catalina.policy, with fix from comment #6 on the last line.
catalina.out contents: Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:222) at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:171) at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:243) at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:298) at org.apache.catalina.startup.Bootstrap.<clinit>(Bootstrap.java:55) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) Caused by: java.security.AccessControlException: Access denied (java.util.PropertyPermission java.util.logging.config.class read) at java.security.AccessController.checkPermission(AccessController.java:132) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1297) at java.lang.System.getProperty(System.java:404) at java.lang.System.getProperty(System.java:388) at org.apache.juli.logging.DirectJDKLog.<clinit>(DirectJDKLog.java:43) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) ... 6 more Could not find the main class: org.apache.catalina.startup.Bootstrap. Program will exit.
Added DocText. @David, can you please review the Doc Text content?
Removed Release Notes flag and need info. This bug is excluded from release notes as it is part of the internal group.
I have tried with a vanilla Tomcat (tc6.0.x) there is still the error.
And I don't find org.apache.catalina.loader in the patch files.
Created attachment 754702 [details] patch for the issue. Please add the patch to the spec files.
the Doc Text looks OK.
I have made it public.
Created attachment 764980 [details] catalina.out catalina.out from running tomcat with security manager on IBMJDK from EWS-2.0.1-CR3
Bug still present in 2.0.1-CR3
Looking at the out, it seems there are two separate issues. - A JULI initialization issue that I have no particular idea about right now: Jun 24, 2013 10:19:19 AM org.apache.juli.ClassLoaderLogManager readConfiguration WARNING: Reading logging.properties is not permitted in some context. See "per context logging" in the default catalina.policy file. Jun 24, 2013 10:19:19 AM org.apache.juli.ClassLoaderLogManager readConfiguration WARNING: Original error was: Access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.loader) - The "main" issue regarding reading back persisted session objects. IMO, you can only reproduce it if custom objects [from webapp classes] were put into the session (and then serialized). To fix it, I would try preloading org.apache.catalina.loader.ResourceEntry through SecurityClassLoad first, since it is a NCDF, not a simpler class not found. Did someone actually manage to reproduce this ? It's probably not so simple.
I have verified by site and function the patches for rhbz#901801 and rhbz#927930 are being applied correctly and I could not reproduce the issue using openjdk 1.6, tomcat7-7.0.40-5 if the problem exists for only the IBM JDK, i recommend the issue be reported to IBM. (currently the ibm site for download and support requires a UID and password. Despite creating an account i could not get access to these areas.)
(In reply to David Knox from comment #21) > ... I could not reproduce the issue using openjdk 1.6, tomcat7-7.0.40-5 > > if the problem exists for only the IBM JDK, i recommend the issue be > reported to IBM. Using QA test suite this is *only* reproducible on IBM JDK and *not* OpenJDK and OracleJDK.
Michal, since you have the details it would be efficient if you could report this upstream. I don't mind logging the bz, i just think first hand knowledge is always better than second hand knowledge. As part of the information for the new bz, could you add TOMCAT_OPTS=-Djava.security.debug=access,failure in /etc/tomcat7/tomcat7.conf. it will fill catalina.out with a ton of output.
Updated the doc text. Bug moved from fixed to known issue. @lfuka, can you please review the Doc Text content?