Bug 677301

Summary: [RFE] Restart service after a security update
Product: Red Hat Enterprise Linux 5 Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 5.6CC: rbinkhor
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-14 10:55:49 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description J.H.M. Dassen (Ray) 2011-02-14 05:10:14 EST
2. What is the nature and description of the request?

After applying security updates through yum, the affected vulnerability
service is not restarted

3. Why does the customer need this? (List the business requirements here)

Customer's customer was affected by the exim vulnerability even though the
package was patched. Customer failed to restart the service.

4. How would the customer like to achieve this? (List the functional
requirements here)

After discussing the options with customer, they have agreed to get this
feature through yum (yum.conf)

Provide a list of packages in yum.conf. When yum updates the packages, it
checks the list and then restart the corresponding daemon's.

or

Provide a list of packages in yum.conf. Corresponding daemons should be
restarted  only when the --security switch is used[ yum update --security]

If the server is webhosting server, exim, httpd, bind needs to be mentioned
in the list

5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

Update a package affected by any known vulnerability. Check whether the
service is restarted

6. Is there already an existing RFE upstream or in Red Hat bugzilla?

No

7. How quickly does this need resolved? (desired target release)

RHEL 5.7

8. Does this request meet the RHEL Inclusion criteria (please review)

Yes

9. List the affected packages

yum

10. Would the customer be able to assist in testing this functionality if
implemented?

Yes
Comment 2 J.H.M. Dassen (Ray) 2011-02-14 05:37:10 EST
Please note that daemons should not be considered in isolation - the case of
security vulnerabilities affecting the libraries used by particular daemons
should be considered as well.

<http://lists.debian.org/debian-security-announce/2003/msg00202.html>
contains an illustration of how processes incorporating potentially
vulnerable library code could be identified.
Comment 3 seth vidal 2011-02-14 09:14:48 EST
Normally the pkgs condrestart themselves in their %post scriptlet. Why shouldn't this be the same here?

However, if you want to add a forced restart yum-utils does have a plugin called
post-transaction-actions  which allows you to take specific per-package actions based on the pkg name and based on what action is occuring to the package (install, update, remove, any)
Comment 4 James Antill 2011-02-14 10:55:49 EST
> 3. Why does the customer need this? (List the business requirements here)

> Customer's customer was affected by the exim vulnerability even though the
> package was patched. Customer failed to restart the service.

% rpm -q exim
exim-4.63-5.el5_5.2
% rpm -q --scripts exim
[...]
postuninstall scriptlet (using /bin/sh):
if [ "$1" -ge "1" ]; then
	/sbin/service exim  condrestart > /dev/null 2>&1
	mta=`readlink /etc/alternatives/mta`
	if [ "$mta" == "/usr/sbin/sendmail.exim" ]; then
		/usr/sbin/alternatives --set mta /usr/sbin/sendmail.exim
	fi
fi

...so on updates exim is calling condrestart ... now it's possible that condrestart is failing, or something else weird is going on.
 But I'm pretty sure none of this is a yum bug/RFE.

 Also in RHEL-6 (or just newer versions of yum-utils) we have "needs-restarting" and the "ps" yum plugin, both of which help you map running services which have "deleted" components to names/packages/PIDs.