Bug 247251 - rpm does not suggest services to restart after library update
rpm does not suggest services to restart after library update
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Depends On:
  Show dependency treegraph
Reported: 2007-07-06 07:32 EDT by Peter Bieringer
Modified: 2012-06-20 12:04 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 12:04:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Daily check of open files, et.al. (7.64 KB, application/octet-stream)
2007-07-06 07:32 EDT, Peter Bieringer
no flags Details

  None (edit)
Description Peter Bieringer 2007-07-06 07:32:18 EDT
Description of problem:
From security point of view it makes not much sense to update supplied libraries
all the time without restarting the programs which uses this libraries, because
still the old library code would be used and e.g. a network service can be still
exploitable. Reboot after each library update is overkill.

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

How reproducible:
After each library package update

Steps to Reproduce:
Update e.g. on a systems krb5-libs
Take a look on open but deleted files

Actual results:
You will see that programs (e.g. daemons listening on network sockets) still
using the old but deleted library.

Expected results:
rpm at least suggest to restart related programs.

Additional info:
I've created now a cron job, which does this check on regular basis all days and
suggest me a list of services to restart or to reboot the system, if nothing
else would help.

Take this solution as start for discussion, how to solve this issue completly.

For middle term, perhaps every library package can get an additional program
call which (if exists) run the open-but-deleted-file check and automagically
suggests the services which should be restarted.
In case of using yum or up2date, this should only run once after the upgrade, so
the additional program has to detect, whether it was called by postinstall from
standalone rpm usage or triggered via yum|up2date->rpm->postinstall

I've created a rpm package for that and additional checks:

Checks for available packages, if automatic update is not active, search for
open but deleted files and check latest installed against running kernel version.

Checks for packages which are not covered by yum or up2date channels - so
administrator have to look for updates manually here
Comment 1 Peter Bieringer 2007-07-06 07:32:18 EDT
Created attachment 158653 [details]
Daily check of open files, et.al.
Comment 2 Jeff Johnson 2007-07-07 19:38:52 EDT
Restarting running processes to insure that libraries with security updates
are used by persistent processes is outside the scope of package management.

Your goal can be accomplisehed without any assistance from rpm applications, as you have shown.
Comment 3 Peter Bieringer 2007-07-08 04:24:46 EDT
But the current problem is, that the "check" process needs to be started by rpm,
up2date or yum at the end of each run, so a hook or trigger would be needed - or
an optional wrapper.

Currently, my check is started by cron each day, this can be too late in
important security cases.
Comment 4 Peter Bieringer 2007-07-13 08:17:16 EDT
I cloned bug for Fedora devel for more discussion:
Also I've submitted a stand-alone test program:
Feel free to test your systems for missing service restarts.
Comment 5 Jiri Pallich 2012-06-20 12:04:48 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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