In previous versions of JBoss EAP 6, servers in a managed domain would not launch successfully if they were configured to use a Java Security Manager without specifying the classname of the Security Manager.
For example, this is commonly done when using the default Security Manager by specifying `-Djava.security.manager` in either` domain.conf` or as a command line parameter.
This issue occurred because a system property without a value was passed by Host Controllers to their managed servers with the value of `true`. This meant that the servers would incorrectly attempt to use a Java Security Manager with the classname of `true`.
This issue has been fixed in this release by adding extra checks for host controller system properties so that a system property is passed to the managed servers correctly. As a result, using a managed domain and using the default Security Manager by specifying `-Djava.security.manager` should function as expected.
Process described in the Security Guide and Administration guide doesn't enable security manager for domain mode.
The problem is caused by missing arguments in PROCESS_CONTROLLER_JAVA_OPTS and HOST_CONTROLLER_JAVA_OPTS which don't take a new line added at the end of domain.conf into account.
If the security manager is configured for a host controller (i.e. -Djava.security.manager used in HOST_CONTROLLER_JAVA_OPTS), then the domain doesn't start.
Log file contains:
09:12:58,931 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:server-one'
[Server:server-one] Error occurred during initialization of VM
[Server:server-one] java.lang.InternalError: Could not create SecurityManager: true
[Server:server-one] at sun.misc.Launcher.<init>(Launcher.java:106)
[Server:server-one] at sun.misc.Launcher.<clinit>(Launcher.java:57)
[Server:server-one] at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1489)
[Server:server-one] at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1474)
09:12:59,045 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 1
Steps to reproduce:
1. create /tmp/ permit.policy file with content:
2. add following line at the beginning of domain.conf:
JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==/tmp/permit.policy -Djava.security.debug=failure"
3. run ./domain.sh
Darran Lofthouse <email@example.com> made a comment on jira WFLY-2585
In addition to the access control related changes thoroughly check additional places where the current AccessControlContext is obtained within a PriviledgedAction.
Some places may want a clean AccessControlContext that looses the information about the caller, others may genuinely want the current AccessControlContext but instead accidentally replace it.
Darran Lofthouse <firstname.lastname@example.org> updated the status of jira WFLY-2585 to Coding In Progress
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1035477 for the incorrect documentation advising setting JAVA_OPTS at the end of domain.conf.
I found it.
The propagation of system properties from the command line / scripts through the PC/HC and to the server process launch is resulting in:
The latter fails.
So this is unrelated to the WFLY-2585 issue.
Note that -Djava.security.policy==/tmp/permit.policy needs to have one '=' removed or you'll get failures.
Two equal signs '==' is a valid syntax for setting a policy file.
The documentation says:
If you use
java -Djava.security.manager -Djava.security.policy==someURL SomeApp
(note the double equals) then just the specified policy file will be used; all the ones indicated in the security properties file will be ignored.
https://github.com/jbossas/jboss-eap/pull/715 replaces 714, and fixes the double '=' case.
Verified on EAP 6.3.0.DR0.
Minor edits to release notes text
Josef: See Scott Mumford's request above. I did not make this private and don't know if the setting should be cleared or not.