« Leading horses to waterMiedo, Incertidumbre, y Duda »



Permalink 03:43:12 pm, by fumanchu Email , 609 words   English (US)
Categories: IT


I'm finally going to be honest and admit I have a problem. I have a persistent fear: a fear of software installers. I don't mean that I dislike installing software. Rather, I shy away at every opportunity from writing software which requires an installer. My preferred method of installation is "copy these files". I'm always impressed by web applications which you install by copying files, and configure by visiting the application itself.

This fear definitely affected the design of my most recent application, Newspeak, which is a rule-helper for SpamAssassin. You use Newspeak to add phrases to a custom ruleset. However, the SpamAssassin daemon won't read the new rules without restarting the process, and the process needs to be restarted by the root user. The webpage script, however, is usually running under the www-data user.

This is not a new problem in the world of web applications. It is such an old problem, in fact, that many strategies have already been tried and found lacking for one reason or another. You get a feel for this when reading the documentation for these strategies, most of which say DON'T EVER DO THIS multiple times. You'll also find that many of them have simply been disabled, or are deliberately confusing.

The problem is compounded by the fact that so many layers are working together to produce what seems like a simple web page. The page itself is served by a script, written in Python, being served by Apache, running on Debian Linux; it needs to restart the spamd process, which was started by the /etc/init.d/spamassassin shell script, which uses Debian's stop-start-daemon (which wrote spamd's pid into /var/run/spamd.pid). Confused yet? If not, which of those pieces do you modify to get the spamd process restarted?

My answer was, "none of the above". You can't modify Apache to use suexec, because it only works if the desired user is not root. You can't setuid the CGI script itself--you would have to setuid the python executable. You shouldn't run Apache as the root user--that's way too many privileges site-wide for the sake of a single script. You can't write a setuid shell script to call kill -HUP for you--you'd have to make bash itself setuid root (and to make it so would be very dangerous). Perl addresses that last issue by automatically wrapping setuid scripts with its own suid wrapper, so I suppose one solution would be to rewrite the Python script in Perl. That's a lot of work for someone who hasn't written much Perl and doesn't care to. ;)

You could write a small C program to wrap the kill -HUP call. This seems to be the most commonly-recommended method these days. But now we've come back to the original topic: if I distribute this program, I now have to either:

  1. Ask every deployer to compile the C program themselves, or
  2. Use an installer (effectively doing the work of all those deployers myself).

Neither of those options are very appealing.

For what it's worth, I ended up writing a separate process, which runs as a daemon (as root), and listens on localhost for TCP. When it receives any message on its port, it restarts spamd. [I was a bit disappointed to find sockets were the best IPC mechanism available on Unix to communicate between dissimilar users--why can't www-data send a lowly SIGUSR1 to a root process?]. So now the deployer must arrange for that daemon to run on startup.

Is that overkill to avoid my installaphobia?

Newspeak (alpha code) can be found at svn://casadeamor.com/newspeak/trunk

No feedback yet

Leave a comment

Your email address will not be revealed on this site.

Your URL will be displayed.

Please enter the phrase "I am a real human." in the textbox above.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
September 2020
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      


The requested Blog doesn't exist any more!

XML Feeds

powered by b2evolution free blog software