Bug 1035232 - [CCC] (6.3) EAP Domain mode is not working properly with Security manager
Summary: [CCC] (6.3) EAP Domain mode is not working properly with Security manager
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: DR0
: EAP 6.3.0
Assignee: Brian Stansberry
QA Contact: Petr Kremensky
Lucas Costi
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1036618 1040480 1044394 1053404
TreeView+ depends on / blocked
 
Reported: 2013-11-27 11:00 UTC by Josef Cacek
Modified: 2014-07-21 03:15 UTC (History)
13 users (show)

(edit)
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.
Clone Of:
: 1117290 (view as bug list)
(edit)
Last Closed: 2014-06-28 15:26:29 UTC
brian.stansberry: needinfo-


Attachments (Terms of Use)

Description Josef Cacek 2013-11-27 11:00:55 UTC
Process described in the Security Guide and Administration guide doesn't enable security manager for domain mode.
http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/Security_Guide/index.html#Run_JBoss_Enterprise_Application_Platform_Within_the_Java_Security_Manager
http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Administration_and_Configuration_Guide/Run_JBoss_Enterprise_Application_Platform_Within_the_Java_Security_Manager.html

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)
[Server:server-one] 
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:
grant {
   permission java.security.AllPermission;
};
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

Comment 1 JBoss JIRA Server 2013-11-27 14:08:43 UTC
Darran Lofthouse <darran.lofthouse@jboss.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.

Comment 2 JBoss JIRA Server 2013-11-27 18:13:47 UTC
Darran Lofthouse <darran.lofthouse@jboss.com> updated the status of jira WFLY-2585 to Coding In Progress

Comment 5 Brian Stansberry 2013-11-27 21:25:49 UTC
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.

Comment 6 Brian Stansberry 2013-11-27 21:44:35 UTC
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:

-Djava.security.manager

becoming

-Djava.security.manager=true

The latter fails.

So this is unrelated to the WFLY-2585 issue.

Comment 7 Brian Stansberry 2013-11-28 00:29:51 UTC
Note that -Djava.security.policy==/tmp/permit.policy needs to have one '=' removed or you'll get failures.

Comment 9 Josef Cacek 2013-11-28 07:02:24 UTC
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.

cf. http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html

Comment 10 Kabir Khan 2013-11-28 12:43:16 UTC
https://github.com/jbossas/jboss-eap/pull/715 replaces 714, and fixes the double '=' case.

Comment 16 Ondrej Lukas 2014-02-26 09:48:24 UTC
Verified on EAP 6.3.0.DR0.

Comment 19 Scott Mumford 2014-05-14 02:28:33 UTC
Minor edits to release notes text

Comment 21 Brian Stansberry 2014-07-07 13:56:59 UTC
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.


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