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
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 =============================================================================
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.
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.
David Lloyd <david.lloyd> updated the status of jira WFLY-1466 to Resolved
David Lloyd <david.lloyd> 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.
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
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?
Setting for exclusion from 6.1.1 Release notes and removing NEEDINFO request.
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.