RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

  $TOMCAT_GROUP doesn't effect in /etc/sysconfig/tomcat6.

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

  tomcat6-6.0.24-62.el6.noarch

How reproducible:

  Always.

Steps to Reproduce:
1. Add the following line to /etc/sysconfig/tomcat6 .

  TOMCAT_GROUP="apache"

2. Make the following files and directories writable somehow.
  # cd /usr/share/tomcat6/logs/
  # chmod 777 *
  # cd /usr/share/tomcat6/work/Catalina/localhost/
  # chmod -R 777 host-manager sample

3. Restart tomcat6
  # service tomcat6 restart

4. Check the process's gid.

  # ps -eo pid,egid,fgid,gid,pgid,rgid,sgid,svgid,tpgid


Actual results:

  # ps -eo pid,egid,fgid,gid,pgid,rgid,sgid,svgid,tpgid | grep `pgrep java`
  4947    91    91    91  4921    91    91    91    -1

gid is still tomcat's.


Expected results:

  # ps -eo pid,egid,fgid,gid,pgid,rgid,sgid,svgid,tpgid | grep `pgrep java`
 4947    48    48    48  4921    48    48    48    -1


Additional info:

> $TOMCAT_GROUP doesn't effect in /etc/sysconfig/tomcat6.

That's not totally true :) It _does_ affect ownership of the PID file:

[root@rhel6 ~]# ls -l /var/run/tomcat6.pid 
-rw-r--r--. 1 tomcat apache 5 Nov 23 15:17 /var/run/tomcat6.pid

What it doesn't do is affect the process ownership because we use su to start tomcat:

[ "$RETVAL" -eq "0" ] && $SU - $TOMCAT_USER -c "${TOMCAT_SCRIPT} start" >> ${TOMCAT_LOG} 2>&1 || RETVAL="4"

We could do something like check the user and see if it's the same as the group and if so, use su; otherwise use sg to start with the specified group. I'm just not sure we can do both...

I'm still looking into this one.

We might be able to use sudo:

sudo -g $TOMCAT_GROUP -u $TOMCAT_USER -s "${TOMCAT_SCRIPT} start"

but my first pass gives me an error:

Sorry, user root is not allowed to execute '/bin/bash -c /usr/sbin/tomcat6\ start' as tomcat:apache on rhel6.

After some more researching me--

runuser is just missing the group (-g) flag.

As it turns out, implementing this fix causes a few issues for layered products (specifically Satellite). Given that fact and the fact that there aren't any other requests to have this included, I will be closing the issue.