Problem with /sbin/service stop FOO in uninstall scripts...

[Phil Knirsch]

Hi folks.

I stumbled across a problem today which at first sight might sound 
trivial and irrelevant, but i'll come to some examples later.

The problem is that hardly any of the uninstall scripts which have a 
service they want to stop ever check if the service is running at all.

They usually simply do a:

if [ "$1" = 0 ]; then
     /sbin/service FOO stop >/dev/null 2>&1
     /sbin/chkconfig --del FOO
fi

Thats nice and fine in the general case, but as soon as you are working 
in a chroot environment you can get really strange results:

Imagine you are remotely logged into a system via ssh, have a chroot and 
are working in it and decide to remove the package openssh-server in 
that chroot.

What would you except? Surely not that your sshd on the remote system 
suddenly stops. But unfortunately thats what then happens because 
/sbin/service stop calls killproc which first tries to find 
/var/lock/subsys/FOO, then some other checks and if it didn't find 
anything in the end it calls pidof FOO. And that just goes through /proc 
and if it finds a matching name, in that case the sshd of the remote 
system it happily uses that one to kill. Bang! Your sshd is gone. 
Imagine that with a system 100s of miles away...

And thats only 1 example, it can hit you with a rescue system as well 
where you work in a chroot to bring back up your system again.

But there is light at the end of the tunnel: There are several fairly 
straightforward and pretty nice solutions to that problem.

1) As vixie-cron already does simply do this:

if [ "$1" = 0 ]; then
     [ -f /var/lock/subsys/crond ] && /sbin/service crond stop 
 >/dev/null 2>&1
     /sbin/chkconfig --del crond
fi

Nice, easy and understandable. Only stop the service if it is running at 
all. This is actually my favourite solution as it's really clean and 
doesn't change behaviour of a system command.

2) Fix /sbin/pidof to check wether the /proc/1/root matches the found 
/proc/$pid/root

This solution would require a fix in pidof. It would also change the 
current behaviour, but arguably to correct a bug that pidof had. Because 
honestly i wouldn't expect pidof to list pids of processes outside of my 
chroot.

3) Fix the inbetweener: killproc() in initrc functions. So basically 
keep pidof as it is but make the check mentioned in 2) in killproc() 
instead.

I see that 3rd solution a way around fixing possibly 76 specfiles in 
devel with solution 1.

Just food for though and comments welcome, as always. I'd really like to 
hear if you think this is a problem, too, or if i am just paranoid. :)

Read ya, Phil

-- 
Philipp Knirsch      | Tel.:  +49-711-96437-470
Development          | Fax.:  +49-711-96437-111
Red Hat GmbH         | Email: Phil Knirsch <phil at redhat.de>
Hauptstaetterstr. 58 | Web:   http://www.redhat.de/
D-70178 Stuttgart
Motd:  You're only jealous cos the little penguins are talking to me.