Re: gLSB: sysinit: clearify algorithm for determining status of programs
Tobias Burnus <[email protected]>
| Newsgroups | gmane.linux.lsb.discuss |
|---|---|
| Message-ID | <[email protected]> |
Hello again, the gLSB 1.3 initfunctions.sgml contains: "If an entry is found in /var/run/basename.pid, then that value is returned. Compliant implementations of the LSB may attempt other mechanisms for determining the pid(s), although this is not required (and not recommended, since a user can trick startup scripts by creating processes that appear to be system programs in the process list thus creating a potential security exposure)." This explicily allows this: first checking for the pidfile and then, if it doesn't exist, checking the /proc system (using e.g. pidof). There are two possible reasons for the case that there is no pidfile present: (a) the program doesn't use pidfiles (implicitly assumed above) or (b) it is not running. This makes trouble when a daemon is started twice with different pid and coniguration files. My all ready cited example, /usr/sbin/sshd (/var/run/sshd.pid) /usr/sbin/sshd -f /etc/ssh/sshd_config2 -p 123 (/var/run/zedv-sshd.pid), shows that pidof $BIN == pidof /usr/sbin/sshd has no chance to discriminate those two. Considering that one can pass a basename instead of a pathname to pidofproc and killproc, things are even worse. I therefore would like to prohibit the checking of other pids but those given in the pidfile. My main problem is that at least three distributions use the pidof fallback: RedHat, SuSE and Debian. Thus I'm a bit reluctant to simply disallow this. Therefore I would really appreciate to get some feedback from the distributions. The current spec (gLSB 1.9-CVS) is now: "Compliant implementations may (but should not) use other mechanisms besides those based on pidfiles." Tobias