Hello ^^)

Le 02/09/2021 à 20:49, Bill Cole a écrit :
On 2021-09-02 at 06:03:22 UTC-0400 (Thu, 2 Sep 2021 12:03:22 +0200)
Jean-François Bachelet <jfbache...@free.fr>
is rumored to have said:

Hello folks ^^)


I've installed the latest spamassassin version on a new Debian 11 server and configured it to work with Postfix, amavis-new, and clamav.

spamassassin got a user named 'spamd' and is run under it.


sa-update is set on a cron job to automate the update but that fails  :(

each day I get that report from cron :


/etc/cron.daily/spamassassin:
mkdir /var/lib/spamassassin/3.004006: Permission denied at /usr/bin/sa-update line 488.
sa-update failed for unknown reasons.


First, I've thinked that it was a permissions problem for 'spamd' user to access the '/var/lib/spamassassin' directory, so I've
'chown -r spamd:spamd /var/lib/spamassassin'

Hopefully that was actually "-R"

yes, it was a typing error there ;)


but even with permissions set to 775 on that directory the update still fail with the same message.

I just can't set permissions to 777 on that kind of directory (I'm not mad),

Right. Using 777 (or 666) anywhere except for directories with the sticky bit set is always wrong.

especially on a web server, we're not on windoze here ^^)


so what is the real problem with sa-update not working under spamassassin's own user when on a cron job on debian 11 ?

You need to run the sa-update cron job as the same user that INSTALLED SpamAssassin, the user who OWNS the local state directory (i.e. /var/lib/spamassassin.) You can make that happen by properly modifying the ownership of the directory or by running the cron job as root.

This was also my answer to the (not-a-)bug report that you opened. There really isn't another answer.

of course it was installed by root, btw, what is the point to have a user 'spamd' or debian-spamd' created if it is of no use ?

in this case the spamd user have all the needed rights to read-modify-execute on the /var/lib/spamassassin directory that its own, the job is run under that user and that don't work ???


wasn't it there for NOT escallating the privileges to 'root' for spamassassin updates and run ? at least it's common sense to avoid such dangerous 'root' use when

using scripts (as cron jobs) mainly for security.

or am I wrong ?


just an example, clamav have its own user and have no problems to auto update itself under it daily.


Jeff


Reply via email to