Bug 901081 (JBEWS-68)

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?