Spamassassin update fails on freshly installed debian 7 server

Submitted by Slikkerveer on Sun, 03/29/2015 - 05:28 Pro Licensee

Hi, on a brand new debian server I get the earlier reported error:

/etc/cron.daily/spamassassin:
channel: attempt to rm channel cf file failed, attempting to continue anyway at /usr/bin/sa-update line 825.
error: can't remove file /var/lib/spamassassin/3.003002/updates_spamassassin_org/30_text_de.cf: Permission denied
channel: attempt to rm channel directory failed, attempting to continue anyway at /usr/bin/sa-update line 828.
error: failed to open /var/lib/spamassassin/3.003002/updates_spamassassin_org/10_default_prefs.cf for write: Permission denied at /usr/bin/sa-update line 1118.
channel: archive extraction failed, channel failed
error: can't remove file /var/lib/spamassassin/3.003002/updates_spamassassin_org/30_text_de.cf: Permission denied
channel: attempt to clean up failed extraction also failed!
sa-update failed for unknown reasons

The issue has been reported before in https://www.virtualmin.com/node/36561 which refers to https://www.virtualmin.com/node/29766, and which solution works (although a simple chown -R debian-spamd:debian-spamd /var/lib/spamassassin would have been sufficient).

However, I am reporting this issue again because it is caused by virtualmin IMHO. During post-installation sa-update seems to have been run as root user. In the debian update script (/etc/cron.daily/spamassassin) sa-update is run as run as unprivileged user debian-spamd, which has no write permissions on the root owned files. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743872. I did not run into this issue 2 years ago with debian 6. For debian 7 systems, in post-installation either:

  • Run sa-update as debian-spamd.
  • Run /etc/cron.daily/spamassassin instead.
  • Do not run sa-update and wait for the cron job do it's work (not tested, may cause issues).
  • Do a chown -R debian-spamd:debian-spamd /var/lib/spamassassin afterwards.

Thank you. (BTW, I love virtualmin/webmin.)

Status: 
Active

Comments

Submitted by andreychek on Sun, 03/29/2015 - 10:55

Howdy -- thanks for letting us know, I'm looking into this.

Submitted by andreychek on Sun, 03/29/2015 - 11:18

I found this Debian bug report on the matter, where they do suggest running it as a non-root user to prevent that issue:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743872

What's curious is that the Virtualmin method of running that command hasn't changed -- Virtualmin has run "sa-update" as root at the end of the install script for a few years now.

Also, when reviewing Ubuntu and CentOS, they both run it as root from cron.

So I'm wondering if Debian perhaps changed it's behavior in regards to sa-update recently, moving it to run as debian-spamd rather than root for security reasons.

I'm looking into the best way to resolve this.

We could add a special case for Debian in the install script.

Another, perhaps simpler, option would be to just not have the install script run that at all, since all the distros run it nightly anyways.