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 _______________________________________________ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev