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.
Created attachment 40688 [details] patch to /etc/rc.d/init.d/functions to fix pidofproc
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.