Bug 963277 - Debugging Java Security Managers results in a StackOverflow on boot
Debugging Java Security Managers results in a StackOverflow on boot
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Security (Show other bugs)
6.1.0
All All
urgent Severity high
: ER4
: EAP 6.1.1
Assigned To: James Perkins
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-15 10:40 EDT by Jesse Sightler
Modified: 2013-09-16 16:20 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Running with a security manager enabled and `-Djava.security.debug=access:failure` results in a StackOverflow error message and an unbootable JBoss Enterprise Application Platform instance. This problem occurs because the AccessControllercontext's debug output to the System streams causes an infinite loop while checking permissions. The root cause of this problem has been identified and it is expected to be fixed in a future release.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-16 16:20:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (1.15 KB, patch)
2013-07-23 18:03 EDT, James Perkins
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-1466 Critical Resolved Debugging Java Security Managers results in a StackOverflow on boot 2016-03-22 09:58 EDT

  None (edit)
Description Jesse Sightler 2013-05-15 10:40:37 EDT
Description of problem:

Running with a security manager enabled and -Djava.security.debug=access:failure results in a StackOverflow and an unbootable JBoss instance.

This is a serious problem, as it makes debugging security policies nearly impossible, despite the fact that this is how our documentation instructs:

https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6-Beta/html-single/Security_Guide/index.html#Debug_Security_Manager_Policies
Comment 1 Dimitris Andreadis 2013-05-16 11:12:52 EDT
Assign the issue to James, since it seems to be logging related:
=============================================================================
we have investigated reported issue #963277. It is regression from EAP 
6.0.1and it seems the problem with security manager debugging is related 
to changes made in the logging subsystem:

https://github.com/jbossas/jboss-eap/commit/ebb13ca169871708c9e9913d2ba2ff455b7acffe
https://github.com/jbossas/jboss-eap/commit/526c2ae7a4194dc6b787c32c5218cea003276900

The AccessControllercontext's debug output to System streams causes infinite loop of checking permissions now. Maybe an additional doPrivileged block could help.

...
	at java.lang.Class.getClassLoader(Class.java:613)
	at org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext(ClassLoaderLogContextSelector.java:84)
	at org.jboss.logmanager.ThreadLocalLogContextSelector.getLogContext(ThreadLocalLogContextSelector.java:58)
	at org.jboss.logmanager.LogContext.getLogContext(LogContext.java:290)
	at org.jboss.as.logging.stdio.LogContextStdioContextSelector.getStdioContext(LogContextStdioContextSelector.java:49)
	at org.jboss.stdio.StdioContext$2.getDelegate(StdioContext.java:151)
	at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:297)
	at sun.security.util.Debug.println(Debug.java:154)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
	at java.security.AccessController.checkPermission(AccessController.java:560)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.Class.getClassLoader(Class.java:613)
	at org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext(ClassLoaderLogContextSelector.java:84)
	at org.jboss.logmanager.ThreadLocalLogContextSelector.getLogContext(ThreadLocalLogContextSelector.java:58)
...

We took a look at the problem reported as #963279 and we didn't find any 
similar bug reported formerly or any information that bug is repaired in 
EAP 6.1.0. It's not regression because it has same behavior in EAP 6.0.1.

QE recommendation:
Issue #963277 is related to debugging. If Ericsson doesn'tuse Security 
Manager, we should not block release because of this issue. If Ericsson 
uses Security Manager, we should get feedback from themabout this issue. 
We should document this issue as known issue and release fix for it as 
one-off right after ga release.

Additional test casesfor security managerare planned for EAP 6.2.0 
release for Common Criteria certification.In tests plan for EAP 6.1.0 we 
have AS TS execution with security manager, all tests passed. We are 
going to include test case for this scenario into test plans for EAP 
6.2.0 release.

Pavel
=============================================================================
Comment 2 James Perkins 2013-05-17 16:44:47 EDT
Any chance an example security policy could be attached? I tried the one on #963279 but I didn't get the stack overflow. I also don't get to the point where EAP boots either.
Comment 3 Jesse Sightler 2013-05-19 15:08:43 EDT
It is the same security policy. If it is not booting, perhaps there is some difference in the stack size? I suspect the failure to boot has the same root-cause.

One of my coworkers also saw this symptom (hang instead of five minute hang followed by stacktrace). I haven't been able to determine what is causing the difference.
Comment 8 JBoss JIRA Server 2013-07-23 10:13:11 EDT
David Lloyd <david.lloyd@redhat.com> updated the status of jira WFLY-1466 to Resolved
Comment 9 JBoss JIRA Server 2013-07-23 10:13:11 EDT
David Lloyd <david.lloyd@redhat.com> made a comment on jira WFLY-1466

The proper way to use a security manager in WildFly is to configure the security manager extension, which also gives you detailed (better) debug logging of permission violations.
Comment 10 James Perkins 2013-07-23 18:03:54 EDT
Created attachment 777491 [details]
Proposed patch

Upgrades the jboss-stdio library which contains a patch to check for reentrancy on the output stream. The jboss-stdio PR was https://github.com/jboss-logging/jboss-stdio/pull/3
Comment 14 Scott Mumford 2013-08-20 23:53:17 EDT
Requesting confirmation that this is no longer a Known Issue and that the above docs text should be listed as Bug Fix and the text rewritten accordingly.

If so, what fix was implemented, and how does the product behave now under those circumstances?
Comment 15 Scott Mumford 2013-08-25 20:53:23 EDT
Setting for exclusion from 6.1.1 Release notes and removing NEEDINFO request.
Comment 16 James Perkins 2013-08-26 13:05:36 EDT
I'm not sure the docs are quite right here. The issue was with how we wrapped stderr and stdout. We used JBoss STDIO which invoked a checks to the security manager from JBoss Log Manager. It was fixed by checking for reentrancy in STDIO.

Note You need to log in before you can comment on or make changes to this bug.