Bug 899187 (JBEWS-292)

Is that the proper option to set for starting with security?

That option sits commented out in sysconfig/tomcat[56]

If we are not going to support setting security based on it, then we should remove it from the configuration file. But it makes sense to look for it in our startup scripts, because otherwise clients will have only one option ot enable security manager - catalina.sh

It seems to be working in tomcat6. 
But the corresponding code is not there in tomcat5, I don't see that option in comment in the sysconfig file for tomcat 5.

We should backport the ability to do so to the tomcat5 rpm.
Moving to 1.0.2 as this is not a blocker.
This should be documented in the Release Notes as a known issue.

Affects: Added: [Release Notes]

Could you tell how did you verify it is working on tomcat6? I don't see it working with tomcat6 nor tomcat5. No idea about rpm but on solaris at least it has no effect.

Documented as a known issue in the EWS 1.0.1 release notes.

Link: Added: This issue is related to JBPAPP-4873

Investigation for 1.0.2 needed.

Release Notes Docs Status: Added: Documented as Known Issue
Writer: Added: rebecca_newton
Release Notes Text: Added:      Setting SECURITY_MANAGER="true" in sysconfig/tomcat5 or sysconfig/tomcat6 has no effect. To start the server securely, users must start with the -secure flag, like so:

    catalina.sh start -secure

    This is a problem upstream and is expected to be fixed for JBoss Enterprise Web Server 1.0.2. 

Dave, can you look into this as well? Thanks!

Raising the priority as it is important to fix the issue here for 1.0.2 release.

The tc versions for the ews packages have been rebased to 5.5.33 and 6.0.32. If this still fails in the rebased versions we can reopen.

Release Notes Docs Status: Removed: Documented as Known Issue Added: Documented as Resolved Issue
Release Notes Text: Removed:      Setting SECURITY_MANAGER="true" in sysconfig/tomcat5 or sysconfig/tomcat6 has no effect. To start the server securely, users must start with the -secure flag, like so:

    catalina.sh start -secure

    This is a problem upstream and is expected to be fixed for JBoss Enterprise Web Server 1.0.2.  Added:      Setting SECURITY_MANAGER="true" in sysconfig/tomcat5 or sysconfig/tomcat6 has no effect. To start the server securely, users must start with the -secure flag, like so:

    catalina.sh start -secure

    This issue is fixed with JBoss Enterprise Web Server 1.0.2. 

The problem described here is within start-up scripts provided by Red Hat but not tomcat itself. So I don't see how a change in tomcat version could possibly help.
Also looking at sbin/tomcat[56], init.d/tomcat[56] and catalina.sh I don't see the problem fixed.

WRT release notes: the parameter is -security

Regards,
Aleksandar

This seems to be working for tomcat6. To confirm: 

Edit /etc/sysconfig/tomcat6: 
SECURITY_MANAGER="true" 

Edit /etc/rc.d/init.d/tomcat6: 
parseOptions 
if [ "$RETVAL" -eq "0" -a "$SECURITY_MANAGER" = "true" ]; then 
>>>> echo "SECURITY MANAGER" >> $TOMCAT_LOG  <<<<

$SU - $TOMCAT_USER -c "${TOMCAT_SCRIPT} start-security" >> $TOMCAT_LOG 2>&1 || RETVAL="4" 
else 

To make sure it's picked up in the wrapper, /usr/sbin/tomcat6: 

elif [ "$1" = "start-security" ]; then 
>>> echo "SECURITY_MANAGER" <<<<

${JAVACMD} $JAVA_OPTS $CATALINA_OPTS -classpath "$CLASSPATH" \ 

In catalina.out I see: 
SECURITY MANAGER 
SECURITY_MANAGER 

Tomcat5 builds are different and the init script does not handle it. 
The following is being added to the tomcat5 builds. 
Added to sysconfig/tomcat5 > 
# JBPAPP-3644 enable security manager in sysconfig 
# Uncomment to start EWS tomcat5 with security manager 
#SECURITY_MANAGER="false" 

Added to tomcat5 init:
if [ "$SECURITY_MANAGER" = "true" ]; then 
  $SU - $TOMCAT_USER -c "$TOMCAT_SCRIPT start -security" >> $TOMCAT_LOG 2>&1 > 
else 
  $SU - $TOMCAT_USER -c "$TOMCAT_SCRIPT start" >> $TOMCAT_LOG 2>&1
fi 

Changes are checked in (dist-4E-ep-5, dist-5E-ep-5, jb-eap-5-rhel-6)

Please, in CR2 include a fix for solaris also. Just FYI on solaris I don't see "start-security" tomcat6 option anywhere. Perhaps that's something unique to RHEL rpm.
David, could you tell which RHEL version's rpm you confirmed to have start-security option present?

It should be 'start -security'. There isn't anything special in the tomcat builds for EWS that denotes solaris.  The correction is in 
tomcat6-6.0.32-5_patch_02.ep5.el6
tomcat6-6.0.32-6_patch_02.ep5.el5
tomcat6-6.0.32-6_patch_02.ep5.el4

tomcat5-5.5.33-7_patch_03.ep5.el6
tomcat5-5.5.33-8_patch_03.ep5.el5
tomcat5-5.5.33-7_patch_03.ep5.el4

I assume RHEL (at least RPM) should have been covered. But in CR2 I don't see anything in solaris builds that would make the option in etc/sysconfig/tomcat[56] SECURITY_MANAGER=true to work. Also I have tested that setting such option has no effect when starting tomcat.

 Is there a change expected in CR3?

My understanding is the dist-5E-ep-5 tomcat build for ews is used for solaris. There is nothing in the tomcat for ews build scripts that specifies the solaris arch.

If catalina.sh is used to start tomcat, as for the zip distro, then the command is indeed 'catalina.sh start -security'. catalina.sh does not read /etc/sysconfig/tomcat[56] 

In the rhel5 tomcat5 for ews rpm, only the initscript reads /etc/sysconfig/tomcat[56]. The wrapper (/usr/bin/dtomcat5), is called with $TOMCAT_SCRIPT start -security.

Using the dist-5E-ep-5 distro rpm
Verified setting SECURITY_MANAGER='true' in /etc/sysconfig/tomcat5 and starting tomcat5 service. The AccessControlException shows that tomcat was invoked with -security

Result in /var/log/tomcat5/catalina.out verifies the setting worked:
java.security.AccessControlException: access denied (java.security.SecurityPermission getProperty.package.definition)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
        at java.security.AccessController.checkPermission(AccessController.java:553)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)


Using the zip distro from the from the same build, starting with 'catalina.sh start -security':
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina)
   at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
   at java.security.AccessController.checkPermis
 

Closing because testing showed the expected behaviour. 

Hello David,

as I stated earlier, I have tested that on solaris, setting the SECURITY_MANAGER="true" has no effect. No matter what startup script I use. I also don't see anything in etc/init.d/tomcat[56] that refers to that variable (neither in any other startup script available on solaris).

Maybe on solaris the init.d scripts are modified? You could look at the solaris ZIP bundles and view the files with a text editor?

Hi Aleks,
Sorry, but as I stated earlier, there is nothing in the tomcat builds for ews that denotes solaris. There is no 'solaris zip bundle' in the tomcat builds that I manage. The only zip bundles for tomcat ews are similar in name to: 
-- tomcat5-zip-5.5.33-14_patch_04.ep5.el5.noarch.rpm 
which I've shown tested previously.

Hello David, I installed a RHEL4 machine just for making a quick check how are things there. Just tested that on RHEL4 only /etc/init.d/tomcat6 regards the SECURITY_MANAGER variable. I appears init.d scripts are different between RHEL4/5/6 and solaris?
If you are not the right person to handle this issue maybe we can assign back to Permaine?

Hi Aleks,
Perhaps. Can you attach the solaris initd script here? Perhaps I can tell what the origin might be.

Attaching init scripts from solaris.
Please note that RHEL4 tomcat5 script is also missing security manager handling!

Attachment: Added: tomcat5
Attachment: Added: tomcat6

Comparison of the current rhel tomcat5 initscript to the same for solaris.

Attachment: Added: tomcat5-init-solaris_to_rhel.patch

The solaris initscript is quite different from its rhel cousin. I don't think the origin is the initscript from the tomcat ews build because the differences are too extensive. There is a diff attached showing the extent of the differences.

The difference relevant to this issue is:
   {noformat} $SU - $TOMCAT_USER -c "$TOMCAT_SCRIPT start" >> $TOMCAT_LOG 2>&1 {noformat}

should be 
{noformat}    if [ "$SECURITY_MANAGER" = "true" ]; then
       $SU - $TOMCAT_USER -c "$TOMCAT_SCRIPT start -security" >> ${TOMCAT_LOG} 2>&1
    else
       $SU - $TOMCAT_USER -c "$TOMCAT_SCRIPT start" >> ${TOMCAT_LOG} 2>&1
    fi
{noformat}

For tomcat6 change 'start -security' to 'start-security'

reassigning to mladen

Appears to be a solaris specific problem

Resolved by modifying catalina.sh to switch to -security mode if SECURITY_MANAGER=true is set

Modified the RN text, please let me know about accuracy.

Release Notes Text: Removed:      Setting SECURITY_MANAGER="true" in sysconfig/tomcat5 or sysconfig/tomcat6 has no effect. To start the server securely, users must start with the -secure flag, like so:

    catalina.sh start -secure

    This issue is fixed with JBoss Enterprise Web Server 1.0.2.  Added:      Setting SECURITY_MANAGER="true" in sysconfig/tomcat5 or sysconfig/tomcat6 has no effect. This issue has been resolved by modifying catalina.sh to switch to -security mode if SECURITY_MANAGER=true is set.

Mladen, starting server when SECURITY_MANAGER is "true" results in:
{code}/opt/redhat/ews/share/tomcat5/bin/catalina.sh: cannot shift{code}

Looking at catalina.sh it seems shift should be called only if the -security is a command line parameter which is *NOT* the case when the variable is set.

Right. Modifying catalina.sh was a wrong approach.
The latest (CR4) builds will have modified sbin/tomcatX and etc/init.d/tomcatX
scripts that will add -security cmdline param when invoking catalina.sh if
SECURITY_MANAGER is set to true.
This is how RHEL operates anyway.

Fixed in the latest builds

This seems working now.

Attachment: Added: policy_debug.log

Pavel, this JIRA concerns enabling security manager through sysconfig/tomcat[56] and as far as I see it is resolved. Lets use JBPAPP-6133 to track the issue you are seeing further.

Link: Added: This issue is related to JBPAPP-6133

and JBPAPP-4873

Release Notes Docs Status: Removed: Documented as Resolved Issue 
Writer: Removed: rebecca_newton 
Release Notes Text: Removed:      Setting SECURITY_MANAGER="true" in sysconfig/tomcat5 or sysconfig/tomcat6 has no effect. This issue has been resolved by modifying catalina.sh to switch to -security mode if SECURITY_MANAGER=true is set.