Bug 57526

Summary: pidofproc not accurate if /var/run pid file out of sync
Product: [Retired] Red Hat Linux Reporter: ken
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED DEFERRED QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-29 19:29:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to /etc/rc.d/init.d/functions to fix pidofproc none

Description ken 2001-12-14 21:16:41 UTC
Description of Problem:
The pidofproc function in /etc/rc.d/init.d/functions does not return the
proper PID for a process if the /var/run/WHATEVER.pid file is out of sync 
with the actual PID of the running program. pidofproc will return the 
contents of the /var/run/WHATEVER.pid after simply checking that the 
process exists and not checking that the program running at the PID is the 
same as the one that is supposed to be running.

The /var/run/WHATEVER.pid file can become out of sync if there is an 
improper shutdown (i.e. power loss due to faulty UPS or whatever). Many 
scripts in /etc/rc.d/init.d depend on the daemon function which 
consequently depends on the pidofproc function to see if the process is 
allready running. If for some reason the machine was improperly rebooted 
and some other software is running under the PID described for the pid 
file for the init funtion, the program won't be started up.

I've attached a patch that uses pidof (as used towards the end of the 
function) to attempt to grab the running PID so that a match can be made 
between the PID of the running program and the PID stored in the file. The 
patch could probably be written better, but I'm not exactly sure how I'd 
check reliably for certain processes. pidof seems to work well enough.

Version-Release number of selected component (if applicable):
6.40-1 (but could be any version that has this code)


How Reproducible:
I've seen it at least a number of times right after our crappy UPS's 
started flaking out. The overall problem is not dependably reproduced as 
it relies on the chance that the PID's will be shifted into the right 
place on the next boot. The vulnerability of pidofproc itself is 
dependably reproduced as follows.

Steps to Reproduce:
1. Manually kill a process that is normally run from /etc/rc.d/init.d 
(such as sendmail).
2. Find the process ID of some other process running on the system (such 
as crond or ntpd).
3. Create a pid file in /var/run for the process you killed in step 1 (for 
example /var/run/sendmail.pid for sendmail)
4. Enter the process ID from step 2 into the file from step 3.
5. Attempt to start the program you killed in step 1 via it's script 
in /etc/rc.d/init.d (for example "/etc/rc.d/init.d/sendmail start" for 
sendmail)

Actual Results:
The init script will not start the program/deamon because it sees a 
running process matching the process describe in the /var/run PID file.

Expected Results:
The init script should start the program/deamon since the actual program 
is not running.

Additional Information:
This could open a hole for some serious attacks. If for some reason some 
firewall software doesn't come up, or some other security software doesn't 
come up on reboot because the system "THINKS" the program is allready 
running due to a faulty PID file, then protected resources could go 
unprotected. 

There is also a high chance of annoyance from lack of ability to 
authenticate against mysql servers, or third party radius servers, etc. 
Also, a system may be rendered unable to allow remote connections due to 
lack of xinetd. 

Unfortunately there's no real way to tell what isn't going to start on any 
particular system after a catastrophic failure. The only way to make sure 
everything is running as it should is to either re-boot all machines or 
check manually to make sure that everything is running.

Why is it that we blindly depend on that /var/run PID file anyways? pidof 
seems to do a much better job, and the data is much less likely to be 
stale.

Comment 1 ken 2001-12-14 21:20:26 UTC
Created attachment 40688 [details]
patch to /etc/rc.d/init.d/functions to fix pidofproc

Comment 2 Bill Nottingham 2005-09-29 19:29:42 UTC
Closing bugs on older, no longer supported, releases. Apologies for any lack of
response.

If this persists on a current release, such as Fedora Core 4, please open a new bug.