Mailing List Archive

problems updating when using a cron job on debian 11
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'

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), so what is the real problem with sa-update not working under spamassassin's own user when on a cron job on debian 11 ?


Thanks,

Jeff
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Hello Jeff,

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

Are you sure? Note the user and group:

$ ls -ald /var/lib/spamassassin
drwxr-xr-x 6 debian-spamd debian-spamd 81 Apr 3 06:15 /var/lib/spamassassin

Ciao,
David
Re: problems updating when using a cron job on debian 11 [ In reply to ]
On Thursday 02 September 2021 at 12:03:22, Jean-François Bachelet wrote:

> Hello folks ^^)
>
>
> I've installed the latest spamassassin version on a new Debian 11 server

How did you install it?


Antony.

--
Schrödinger's rule of data integrity: the condition of any backup is unknown
until a restore is attempted.

Please reply to the list;
please *don't* CC me.
Re: problems updating when using a cron job on debian 11 [ In reply to ]
On 2021-09-02 at 06:03:22 UTC-0400 (Thu, 2 Sep 2021 12:03:22 +0200)
Jean-François Bachelet <jfbachelet@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"

> 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.

> 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.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: problems updating when using a cron job on debian 11 [ In reply to ]
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 <jfbachelet@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
Re: problems updating when using a cron job on debian 11 [ In reply to ]
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 <jfbachelet@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
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Hello ^^)

Le 02/09/2021 à 13:04, David Bürgin a écrit :
> Hello Jeff,
>
>> spamassassin got a user named 'spamd' and is run under it.
> Are you sure? Note the user and group:
>
> $ ls -ald /var/lib/spamassassin
> drwxr-xr-x 6 debian-spamd debian-spamd 81 Apr 3 06:15 /var/lib/spamassassin

at isntall time I've choosen 'spamd' as user

btw just a user name change does not justify a non working process, all
is done as specified and owner, group, permissions on directory are
right for that user.


Jeff
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Hello ^^)


Le 02/09/2021 à 13:07, Antony Stone a écrit :
> On Thursday 02 September 2021 at 12:03:22, Jean-François Bachelet wrote:
>
>> Hello folks ^^)
>>
>>
>> I've installed the latest spamassassin version on a new Debian 11 server
> How did you install it?

'apt install' spamassassin spamc    (as all the other stuff that works
on that server.)

then,

user create

'useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin spamd'

mkdir /var/lib/spamassassin

chown -R spamd:spamd /var/lib/spamassassin

edit the confs and integration into postfix/amavis-new

enable and check status


that's only the day after that I've got cron warnings that it can't do
it's job as expected...


Jeff
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Re 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 <jfbachelet@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"
>
>> 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.
>
>> 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.

here is the conf files that activate the cron job : (I'm using nano line
numbered so ignore)


 1 # /etc/default/spamassassin
 2 # Duncan Findlay
 3
 4 # WARNING: please read README.spamd before using.
 5 # There may be security risks.
 6
 7 # Prior to version 3.4.2-1, spamd could be enabled by setting
 8 # ENABLED=1 in this file. This is no longer supported. Instead, please
 9 # use the update-rc.d command, invoked for example as "update-rc.d
10 # spamassassin enable", to enable the spamd service.
11
12 # Options
13 # See man spamd for possible options. The -d option is automatically
added.
14
15 # SpamAssassin uses a preforking model, so be careful! You need to
16 # make sure --max-children is not set to anything higher than 5,
17 # unless you know what you're doing.
18
19 OPTIONS="--create-prefs --max-children 5 --username spamd
--helper-home-dir /var/lib/spamassassin -s /var/lib/spamassassin/spamd.log"
20
21 # Pid file
22 # Where should spamd write its PID to file? If you use the -u or
23 # --username option above, this needs to be writable by that user.
24 # Otherwise, the init script will not be able to shut spamd down.
25 #PIDFILE="/var/run/spamd.pid"
26
27 # Set nice level of spamd
28 #NICE="--nicelevel 15"
29
30 # Cronjob
31 # Set to anything but 0 to enable the cron job to automatically update
32 # spamassassin's rules on a nightly basis
33 CRON=1
34

is there something wrong / forgotten there ?

Jeff
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Jean-Fran?ois Bachelet wrote:
> Le 02/09/2021 ? 13:07, Antony Stone a ?crit :
> > How did you install it?
>
> 'apt install' spamassassin spamc (as all the other stuff that works on that server.)

At that moment permissions were correct and everything was set to work
correctly.

> then,
> user create
> 'useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin spamd'
> mkdir /var/lib/spamassassin
> chown -R spamd:spamd /var/lib/spamassassin

At that moment the installation was broken by these actions!
Permissions and ownership were set so as to prevent it from working.
Broken! :-(

Bob
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Hello bob ^^)


Le 03/09/2021 à 09:11, Bob Proulx a écrit :
> Jean-François Bachelet wrote:
>> Le 02/09/2021 à 13:07, Antony Stone a écrit :
>>> How did you install it?
>> 'apt install' spamassassin spamc (as all the other stuff that works on that server.)
> At that moment permissions were correct and everything was set to work
> correctly.
>
>> then,
>> user create
>> 'useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin spamd'
>> mkdir /var/lib/spamassassin
>> chown -R spamd:spamd /var/lib/spamassassin
> At that moment the installation was broken by these actions!
> Permissions and ownership were set so as to prevent it from working.

ok, so what should be the right things to do here ? without explaining
what's wrong that doesn't help.


Jeff
Re: problems updating when using a cron job on debian 11 [ In reply to ]
On Friday 03 September 2021 at 11:23:19, Jean-François Bachelet wrote:

> Le 03/09/2021 à 09:11, Bob Proulx a écrit :
> > Jean-François Bachelet wrote:
> >
> >> user create
> >> 'useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin
> >> spamd' mkdir /var/lib/spamassassin
> >> chown -R spamd:spamd /var/lib/spamassassin
> >
> > At that moment the installation was broken by these actions!
> > Permissions and ownership were set so as to prevent it from working.
>
> ok, so what should be the right things to do here ? without explaining
> what's wrong that doesn't help.

Install the package and do not create users or modify ownerships / permissions
afterwards.


Antony.

--
"Hi, I've found a fault with the English language and I need an entomologist."
"I think you mean an etymologist."
"No. It's a bug, not a feature."

Please reply to the list;
please *don't* CC me.
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Le 03/09/2021 à 14:13, Reindl Harald a écrit :
>
>
> On 03.09.21 11:23, Jean-François Bachelet wrote:
>> Le 03/09/2021 à 09:11, Bob Proulx a écrit :
>>> Jean-François Bachelet wrote:
>>>> Le 02/09/2021 à 13:07, Antony Stone a écrit :
>>>>> How did you install it?
>>>> 'apt install' spamassassin spamc    (as all the other stuff that
>>>> works on that server.)
>>> At that moment permissions were correct and everything was set to work
>>> correctly.
>>>
>>>> then,
>>>> user create
>>>> 'useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin
>>>> spamd'
>>>> mkdir /var/lib/spamassassin
>>>> chown -R spamd:spamd /var/lib/spamassassin
>>> At that moment the installation was broken by these actions!
>>> Permissions and ownership were set so as to prevent it from working.
>>
>> ok, so what should be the right things to do here ? without
>> explaining what's wrong that doesn't help.
>
> for the sake of god don't change things you do not understand - the
> distribution prepared everything so that it works out of the box on
> thousands of setups, you touch everything left and right and then ask
> the *upstream* community how to fix what you broke

work out of the box when installed standalone... yes.

but is the integration with a bunch of others that need to run in close
cooperation automatically handled by the individual installers in all
situations/operating systems flavours ? really ?


> even if that woul dhave worked shortly there are good chances that
> cron-scripts and package-scripts later would touch the permsisions
> again because they look like need to be fixed

I've just picked the latest tuto I found for
postfix/clamav/spamassassin/amavis-new integration. if it are so wrong
why aren't it been corrected since it was published ?

btw, doesn't we all learn from our errors ? ^^)


Jeff
Re: problems updating when using a cron job on debian 11 [ In reply to ]
Jean-François Bachelet wrote:
> Hello bob ^^)
>

1) OK.  Relevant perms on an Ubuntu system:

/var/lib is 755 owned by root
/var/lib/spamassassin is 755 owned by debian-spamd
/var/lib/spamassassin/3.004006 is owned by root (installer)
/var/lib/spamassassin/compiled is owned by debian-spamd
/var/lib/spamassassin/sa-update-keys is owned by debian-spamd
/var/lib/amavis is 750 owned by amavis
Home directory for amavis is: /var/lib/amavis
Home directory for spamassassin is: /var/lib/spamassassin

NOTE: I use Amavis.  EUID is a user called amavis.  That's fine, it only
read access to any spamassassin files anyway.  If you do any exotic
logging with Amavis, make sure the amavis home directory is writeable to
amavis.  The default quarantine folder is usually under /var/lib/virusmails.

2) On stock Ubuntu, there is a cron job called
/etc/cron.daily/spamassassin that runs.  That runs sa-compile as
debian-spamd.  You don't need sticky bits anywhere or SUIDROOT.

3) So, you're likely to be having issues with SELinux/AppArmor******. 
You'll probably want to have a normal shell, /bin/sh, for both the
debian-spamd and amavis users.  You might see errors in the
/var/log/apport.log file on Ubuntu, /var/log/syslog and/or
/var/log/kern.log on Debian.

FWIW,

-- Jared Hall
Re: problems updating when using a cron job on debian 11 [ In reply to ]
On 2021-09-02 at 18:55:21 UTC-0400 (Fri, 3 Sep 2021 00:55:21 +0200)
Jean-François Bachelet <jfbachelet@free.fr>
is rumored to have said:

> 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 ?

The definitive answer for your case would have to come from the Debian
package maintainer. SpamAssassin as distributed by ASF doesd not create
a special user and does not require one and it also does not have any
facility for optionally running a cron job. The existence of
/etc/default/spamassassin is entirely the work of the Debian packager.

Typically, the reason one would have a 'spamd' user would be to run the
spamd daemon.

> 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 ???

Are you certain that the cron job is running as spamd? It is conceivable
that whatever mechanism Debian has created to consume that conf file
with the CRON switch also makes assumptions about the user it must run
as, e.g. that the installation creates a 'debian-spamd' user
unconditionally and uses that.

My only other *guess* at a root cause would be a problem with an
additional security layer such as AppArmor or SELinux.

> 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 ?

The spamd daemon can optionally use a fixed unprivileged user for its
processing children (-u flag) and you should NOT give that user write
permissions to anything, especially if you have spamd listening on a
network port (as opposed to only using a socket node.) The point of that
user is because spamd is processing potentially malicious input (email)
from untrusted senders, and if it's talking across a network,
potentially from malicious clients. Also using that user to automate
system-wide configuration of SpamAssassin with rule updates would create
the potential weakness of a subverted spamd process being able to make
persistent changes to the SA config.

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

Yes, it is possible to implement such a model. That's not a wrong
choice, it's just not our choice.

SA is primarily a collection of Perl modules, which can be used by
anything that can load Perl modules. Having an unprivileged user whose
primary purpose is to run spamd child processes also own the system-wide
rules does not make sense as a default in
the SA distribution. We do not release a turnkey spam filtering system,
but rather a flexible set of tools that packagers (i.e. Debian) and end
users (i.e. you) can configure and integrate to other tools to fit their
specific needs. If you read the man page for spamd, you'll see that it
has a complex set of user-conscious options to enable all of the many
different ways people have decided to use it. Debian has chosen a
particular style of configuration for SA integration which includes the
/etc/default/spamassassin file as well as whatever consumes that file to
enable a cron job. I don't know what exactly the cron job is doing that
is breaking or why, because I don't have a working Debian installation
of SA handy. I DO have other systems (CentOS, FreeBSD, MacOS) and in all
those cases the sa-update job is run by root, because multiple tools
running as multiple users need to read the rules, but none of those have
any need to write the rules.

ClamAV is a fundamentally different type of toolset. In nearly all
cases, the only consumer of its daily updates are the clamscan and clamd
programs. There are no common circumstances where clamd needs to load
specific per-user configuration or signatures, whereas that is often
done with SA.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: problems updating when using a cron job on debian 11 [ In reply to ]
>Le 02/09/2021 à 20:49, Bill Cole a écrit :
>>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.

On 03.09.21 00:55, Jean-François Bachelet wrote:
>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 ?

IIRC at some time in the past, debian moved from statically created users
for various services and debian-spamd user was created dynamically when
spamassassin got installed.

>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 ???

chown /var/lib/spamassassin/ to debian-spamd.

the debian spamassassin's package uses this user for running sa-update from
cron script.


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...