[spambayes-dev] Running sb_server.py from init under Linux

[Richard Heck]

In response to some questions raised on another list, I've been fiddling
with the initscript provided on the website for sb_server.py. (I'm doing
so under Fedora.) Two questions have arisen.

(1) Is there any reason that sb_server.py needs to run as root? If not,
then it would be very good to run as an unprivileged user. Obviously,
one does not want to think about a malformed email that confuses
spambayes and allows the execution of arbitrary code running in a root
shell.

It's easy enough to modify the initscripts so that sb_server.py runs as
an unprivileged user, but it would be more secure if sb_server.py
lowered its own privilege level. Running it as e.g. user spambayes from
init requries that this user have access to a shell, whereas by lowering
privilege from within sb_server.py you can run as a user who has no
shell access. (FYI: The initscript for the Cyrus IMAP daemon seems to
use the init method.)

(2) The initscripts call daemon(), which is a function defined in the
init function library and which does various other things but basically
just starts whatever program it's told to run. In particular, although
called "daemon", this function does NOT daemonize that program. As a
result, when the initscript runs

daemon /usr/local/bin/sb_server.py &

daemon() blocks, waiting for sb_server.py to finish, although of course
the initscript itself continues, since daemon() is running in the
background. As a result, the usual "OK" signal does not get printed, and
we're left with extra processes hanging around:

 1083 pts/1    S      0:00 /bin/sh /etc/init.d/spambayes start
 1085 pts/1    S      0:00 initlog -q -c runuser -s /bin/bash - spambayes -c "/usr/bin/sb_server.py"
 1086 pts/1    S      0:00 runuser -s /bin/bash - spambayes -c /usr/bin/sb_server.py
 1087 pts/1    S      0:00 /usr/bin/python /usr/bin/sb_server.py

This can be resolved by running instead

daemon "/usr/local/bin/sb_server.py&"

Now daemon() calls "/usr/local/bin/sb_server.py&" and puts the job into
the background. But this is a very ugly hack, or so it seems to me, and
it could cause other problems, because it now looks to daemon() as if
it's been asked to run a program called "sb_server.py&". I think one can
work around that by instead running

daemon --check=sb_server.py "/usr/local/bin/sb_server.py&"

but this is getting messy.

None of this is needed with other servers started via init, like httpd,
because they daemonize themselves. Is it worth considering having
sb_server.py do that, too?

Best,
Richard