Control: severity -1 wishlist
On Wed, Jun 11, 2025 at 11:58:10AM +0200, Vincent Lefevre wrote:
> > In order for user preferences and Bayesian scoring to work, spamd needs
> > to be able to 'su' to the identity of the mail recipient. This is
> > something most people expect to work by default, so spamd runs as root
> > by defaulṫ.
> >
> > A newer version of spamassassin (3.3.2-3, probably) will introduce a
> > debian-spamd user, and it's safe to run spamd as that user if desired.
>
> In the upstream mailing-list, it is said that running spamassassin
> as root is bad for the security. The issue is that several users (including
> me) have
> complained that spamassassin touches the root account.
>
> A recall (a part of) the issue:
>
> Jun 11 11:48:58 joooj spamd[197569]: check: dns_block_rule
> RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating
> /root/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL
> blocked you due to too many queries. Set all affected rules score to 0, or
> use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable
> queries)
> Jun 11 11:48:58 joooj spamd[197569]: check: dns_block_rule
> RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating
> /root/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL
> blocked you due to too many queries. Set all affected rules score to 0, or
> use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
> Jun 11 11:48:58 joooj spamd[197569]: check: dns_block_rule
> RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating
> /root/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked
> you due to too many queries. Set all affected rules score to 0, or use
> "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
>
There's a difference between running spamassassin as root versus running
spamd as root. Spamd runs as root so that it can setuid to the
individual users receiving the incoming mail. This is necessary in
order to support per-user configuration, bayes databases, etc. in
~/.spamassassin.
Quoting spamd's upstream documentation,
When run as root, spamd will change uid's to the user invoking
spamc in order to read and write to their configurations. This
functionality is not possible if spamd does not run as root and is
a disadvantage if you rely on this. If you use mysql or LDAP for
per-user configuration there is no reason in the world to run as
root, and this remains fully functional.
See more at https://svn.apache.org/repos/asf/spamassassin/trunk/spamd/README
In some sites, it may make sense to use the alternate configuration
described there, but that's a more involved setup and not something that
we're going to make the default. Thus my reduction of the severity here.
Running spamassassin itself, which is the part that actually processes
inbound mail, as root would indeed be a bad idea. But that doesn't happen
by default.
noah
