Bug 834169 - Latest tomcat6 package breaks installing to run as a user other than 'tomcat' that is in group 'tomcat'
Latest tomcat6 package breaks installing to run as a user other than 'tomcat'...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: tomcat6 (Show other bugs)
Unspecified Unspecified
unspecified Severity urgent
: rc
: ---
Assigned To: Coty Sutherland
Depends On:
  Show dependency treegraph
Reported: 2012-06-21 01:52 EDT by Sidney Markowitz
Modified: 2015-12-17 13:43 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-17 13:43:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sidney Markowitz 2012-06-21 01:52:27 EDT
Description of problem:

The use case of running tomcat6 as a user other than 'tomcat' by creating a user that is a member of the 'tomcat' group and setting TOMCAT_USER in /etc/tomcat6/tomcat6.conf has been broken by an incorrect file permission installed by the current tomcat6 package.

Installing tomcat6 creates a zero-length file /var/log/tomcat6/catalina.out that has user and group owner tomcat and has permission 644, i.e., no group write permission. This breaks installing tomcat6 with a tomcat user other than 'tomcat' that relies on membership in the tomcat group to work. This is a regression from earlier versions in which either catalina.out was created with group write permission, or it was not created until the first time tomcat6 was run, which would have created the file owned by the user. I don't know which way it was done in older versions.

Version-Release number of selected component (if applicable):

tomcat6.noarch 6.0.24-45.el6

How reproducible: Always

Steps to Reproduce:

1. On RHEL6.3 system without tomcat6 installed, yum install tomcat6

2. Verify that /var/log/tomcat6/catalina.out is owned by tomcat:tomcat and does not have group write permissions. That is a bug.

3. To demonstrate that it breaks, create a user named testcat and add it to group tomcat

4. Edit /etc/tomcat6/tomcat6.conf and change the line TOMCAT_USER="tomcat" to say TOMCAT_USER="testcat"

5. Start up tomcat6 with the command  service tomcat6 start

6. Try running service tomcat6 status and look at the directory /var/log/tomcat6/
Actual results:

The service tomcat6 status command outputs
PID file exists, but process is not running  [FAILED]

/var/log/tomcat6/tomcat6-initd.log contains an error message
"/usr/sbin/tomcat6: line 30: /usr/share/tomcat6/logs/catalina.out: Permission denied"

/var/log/tomcat6/catalina.out is still a zero length file

Expected results:

The service tomcat6 status command should output a line saying that tomcat6 is running

/var/log/tomcat6/tomcat6-initd.log should be a zero length file (no error messages in it)

/var/log/tomcat6/catalina.out should contain various log output from tomcat6

Additional info:

You can demonstrate proper operation by doing chmod g+w /var/log/tomcat6/catalina.out and deleting /var/log/tomcat6/tomcat6-initd.log if it exists from the previous test, then again trying service tomcat6 start to see that changing the permission allows tomcat6 to run correctly.

This is a regression introduced recently. Bug is in tomcat6.noarch 6.0.24-45.el6 and was not in earlier versions. I don't have the exact version in which it was introduced, but I'm pretty sure I didn't see it in installs done in early May.
Comment 2 Sidney Markowitz 2012-06-29 06:43:28 EDT
I tried this out in CentOS 6.2 which right now has tomcat6.noarch 6.0.24-36.el6_2

It works but not in the way that I expected, indicating that the regression is something different than I described.

In that version, doing my steps to reproduce still results in installing with /var/log/tomcat6/catalina.out not having group write permissions.

The different, working, behavior is that when I start up tomcat6 the result is that /var/log/tomcat6/catalina.out is owned by testcat:testcat instead of remaining owned by tomcat:tomcat.

In other words, the startup script or code changes the owner of catalina.out

That makes the regression not a matter of permissions when catalina.out is made, but a matter of change of ownership of that file when tomcat6 is started.
Comment 3 Sidney Markowitz 2012-07-02 22:31:39 EDT
I did a more careful comparison of what is done in RedHat's tomcat6.noarch 6.0.24-45.el6 and CentOS tomcat6.noarch 6.0.24-36.el6_2 to see what the difference is between the nonworking and the working versions.

In /etc/init.d/tomcat6

In CentOS, TOMCAT_LOG is set to /var/log/tomcat6/catalina.out
In RedHat, TOMCAT_LOG is set to /var/log/tomcat6/tomcat6-initd.log

In both, there is then code to set $TOMCAT_LOG's owner to ${TOMCAT_USER}

In the CentOS version tomcat is eventually called with a command line that expands to something like

 su - ${TOMCAT_USER} -c "/usr/sbin/tomcat6 start ${TOMCAT_LOG}" >> /var/log/tomcat6/initd.log 2>&1

In /usr/sbin/tomcat6 the second argument to the script is the path of the log file to which output is appended. Since it is /var/log/tomcat6/catalina.out and the owner has been changed to be TOMCAT_USER then the permissions are fine for that.

As you can see the output for running the su command itself is appended to /var/log/tomcat6/initd.log so that file is written by root.

In the RedHat version the log file name is not passed as an argument to /usr/sbin/tomcat6. Instead /usr/sbin/tomcat6 hard codes the file name catalina.out as the file to log to.

The script is invoked with a command like

 su - ${TOMCAT_USER} -c "/usr/sbin/tomcat6 start" >> ${TOMCAT_LOG} 2>&1

In this case, TOMCAT_LOG is used to log the result of the su command, and catalina.out is the hard coded name used in /usr/sbin/tomcat6. All of the code to chown TOMCAT_LOG to TOMCAT_USER is useless because the su command itself is being run as root. The chown is required for the file that is written by /usr/sbin/tomcat6 which is running as TOMCAT_USER. But the way this is written /etc/init.d/tomcat6 can't know what log file /usr/sbin/tomcat6 is using and so can't fix its ownership. That's why the older version of tomcat in CentOS has to pass the log file name as an argument to /usr/sbin/tomcat6, so that /etc/init.d/tomcat6 can set its owner and then tell /usr/sbin/tomcat6 to use it.
Comment 4 Sidney Markowitz 2012-07-29 06:24:56 EDT
I found an additional problem from the same bug that happens when updating the rpm package if tomcat6 is already properly configured to run as a user other than the default "tomcat".

I downgraded to the earliest version of tomcat that was available and crested catalina.out with the proper ownership for my setup, as would be the correct state when running Tomcat as a user other than tomcat. With tomcat6 configured to run as the testcat user instead of tomcat as described above, I did:

yum downgrade tomcat6-6.0.24-15.el6 tomcat6-admin-webapps-6.0.24-15.el6 tomcat6-lib-6.0.24-15.el6 tomcat6-webapps-6.0.24-15.el6 tomcat6-docs-webapp-6.0.24-15.el6 tomcat6-servlet-2.5-api-6.0.24-15.el6 tomcat6-el-2.1-api-6.0.24-15.el6 tomcat6-jsp-2.1-api-6.0.24-15.el6

cd /var/log/tomcat6
rm catalina.out
gunzip < catalina.out-20120729.gz > catalina.out
chown testcat:testcat catalina.out

I then updated tomcat6 to demonstrate the problem

yum update tomcat6
ls -l /var/log/tomcat6/catalina.out

Expected result: catalina.out still owned by testcat:testcat

Actual result: catalina.out owned by tomcat:tomcat with permission 644 so that service tomcat6 start shows [OK] but does not actually start, showing a permission denied error in /var/log/tomcat6/tomcat6-initd.log
Comment 5 Sidney Markowitz 2012-07-29 20:07:44 EDT
This has become quite urgent for me when I realized that any existing tomcat6 configuration that uses a TOMCAT_USER other than "tomcat" is broken by doing a yum update to this version even if I have worked around the problem during installation of my applications by changing ownership of /var/log/tomcat6/catalina.out.

Partial fix: This isn't a complete way to fix the problem, but it can serve as a compact statement of the problem and the kind of thing that needs to be done.

However it leaves something still wrong: /usr/sbin/tomcat6 now hard codes the name ${CATALINA_BASE/logs/catalina.out as the name of the log file, which means that setting TOMCAT_LOG in tomcat6.conf will not result in logging to someplace other than catalina.out. That will make the following not work if tomcat6.conf sets TOMCAT_LOG to anything other than ${CATALINA_BASE/logs/catalina.out which is why I am writing this as a way of talking about the problem rather than as a real solution.

In /etc/init.d/tomcat6 revert the setting of TOMCAT_LOG to be


After that add the line


Change the four lines that contain >> ${TOMCAT_LOG} to instead say >> ${TOMCAT_INITD_LOG}

Leave all the other code that makes use of TOMCAT_LOG the same, so that the correct log file gets touched and given the proper owners.
Comment 6 Sidney Markowitz 2012-07-29 20:42:57 EDT
Sorry for all the comments, but I just compared CentOS and RedHat versions of tomcat6-6.0.24-15.el6 and I think I see where the bug originated.

The RedHat version 6.0.24-15.el6 has the following bug that the current version seems to try and fail to fix: /etc/init.d/tomcat6 starts tomcat by invoking the script /usr/sbin/tomcat6 redirecting the output of the invoking command line to append to $TOMCAT_LOG which defaults to /var/log/tomcat6/catalina.out if it is not set in tomcat6.conf. But /usr/sbin/tomcat6 always redirects output to append to ${CATALINA_BASE}/logs/catalina.out which breaks in two different ways. 1) It does not respect the setting of TOMCAT_LOG in tomcat6.conf and 2) If TOMCAT_LOG or CATALINA_BASE are not set to their defaults and TOMCAT_USER is not tomcat, then the ownership and permissions of catalina.out will not get set in /etc/init.d/tomcat6 and so tomcat won't start.

CentOS tomcat6-6.0.24-15.el6 fixes both problems by passing $TOMCAT_LOG as an argument to /usr/sbin/tomcat6 so it can redirect to the same log file as is used in /etc/init.d/tomcat6.

RedHat tomcat6-6.0.24-45.el6 instead uses a different file for the log output of the command line that invokes /usr/sbin/tomcat6 and the log output by the java call inside /usr/sbin/tomcat6. That doesn't properly fix problem #1, because /usr/sbin/tomcat6 still does not respect the setting of TOMCAT_LOG in tomcat6.conf. It doesn't fix problem #2 either, because all the work of changing owners of the log file that is done in /etc/init.d/tomcat6 is not done to the file that needs it, which is the log file that is used by /usr/sbin/tomcat6.

I think the correct fix for this is to modify /etc/init.d/tomcat6 and /usr/sbin/tomcat6 the way it is done in CentOS.
Comment 7 RHEL Product and Program Management 2012-12-14 03:41:52 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 10 Coty Sutherland 2015-12-17 13:43:49 EST
Hi Sidney,

We appreciate this bugzilla and the testing that you have done regarding this issue, but at this time we do not plan to include a fix for it in RHEL 6. I've looked into this a good bit and it seems that in RHEL 7 (and Fedora) that it is a non-issue because the TOMCAT_USER variable is not respected and the tomcat user always owns the tomcat process.

If this issue is causing you a significant production issue, please open a support case in the Red Hat Customer Portal.


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