SpamAssassin's daemon spamd runs as root (Debian 11)

While looking for ways to improve HestiaCP’s mail subsystem, I noticed that SpamAssassin spamd runs as root:

[email protected]:~# ps aux
root         1  0.0  0.0 170648  6468 ?        Ss    2021   9:53 /sbin/init
root        38  0.0  0.1  83540 38824 ?        Ss    2021   5:35 /lib/systemd/systemd-journald
root       361  0.0  0.0 102124 10076 ?        Ss    2021  27:28 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/ --create-prefs --max-children 5 --helper-home-dir
root       404  0.0  0.0 102124  6052 ?        S     2021   0:12 spamd child
root       405  0.0  0.0 102124  6712 ?        S     2021   0:11 spamd child
clamav     407  0.0  3.7 1462456 1220068 ?     Ssl   2021  13:33 /usr/sbin/clamd --foreground=true
Debian-+   660  0.0  0.0  33560  7440 ?        Ss    2021   0:03 /usr/sbin/exim4 -bd -q30m
www-data  2678  0.0  0.0  53500  5660 ?        S    Jan15   0:01 nginx: worker process
www-data  2679  0.0  0.0  53500  4036 ?        S    Jan15   0:00 nginx: worker process

There exists a system user “debian-spamd” with shell access but it isn’t used by default. The spamd (perl) daemon binds to tcp/783 where Exim4 connects.

[email protected]:~# fgrep spam /etc/passwd
[email protected]:~# netstat -ntlp -4|fgrep 783
tcp        0      0 *               LISTEN      361/perl            
[email protected]:~#

[email protected]:~# grep -v ^# /etc/default/spamassassin |grep -v ^$
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
[email protected]:~# 

[email protected]:~# fgrep 783 /etc/exim4/exim4.conf.template 
spamd_address = 783
[email protected]:~#

At first thought, it seems that HestiaCP security on Debian 11 hosts can be improved by having spamd run as an unprivileged user (e.g. debian-spamd). For this we would need to have spamd bind to a higher port (e.g. tcp/1783)

By changing /etc/default/spamassassin accordingly e.g.
OPTIONS="-u debian-spamd -p 1783 --create-prefs --max-children 5 --helper-home-dir"

I will also have to check if there are differences with previous supported Debian releases (9 and 10) and how SA is configured under Ubuntu.

I have found several related discussions and bugs filed at Debian’s bugtracker e.g.

The issue of running spamd as root seems to go back almost 20 years. Not sure why they keep doing it (there was an exploit a few years ago), apparently to not break existing SA installations and to allow per-user configurations and to read global whitelist file (?).

More reading is needed …

Checked on my server:


It is strange that spamd is enabled by default

Question: Does SpamAssassin on your system update its rules regularly (using sa-update) ?

Because I just checked the files under /var/lib/spamassassin/ on my HestiaCP test system (Debian 10 with SA v3.4.2) and the latest timestamps are of Apr-2021.

And in the log-files under /var/log grep can’t find anything related to sa-update or spamassassin (other than systemd complains about the path of

Don’t think so. Or otherwise I assume there should be cronjob…

Well on my system there is file /etc/cron.daily/spamassassin …

I just RTFM’ed :grin: and changed CRON=1 in /etc/default/spamassassin

I’ll let you know tomorrow about it …

Quoting from the Debian issue #712564 discussion above:

When spamassassin is running in daemon mode (spamd) as root, the default behaviour is to setuid to the user running spamc. This lets spamd to load and examine the per-user configuration files as the user. So by default, the effective UID is sent to spamd from spamc.

I don’t think HestiaCP uses spamc yet. It could be invoked each time a user moves a mail from Inbox to Spam folder, so that we can have PER-USER spam filter config (note: idea for another feature).

1 Like