after "sa-update" you likely get serious problems if you are running as milter-user or otherwise restricted permissions because the updated rules folder get chmod 750 config: cannot open "/var/lib/spamassassin/3.004000/updates_spamassassin_org.cf" happily i worked around with that in my systemd-unit which is called after successful updates by restart spamd, but that should not happen at all [Service] Environment="TMPDIR=/tmp" PermissionsStartOnly=true ExecStartPre=/usr/bin/find /var/lib/spamassassin/ -type d -exec /bin/chmod 0755 "{}" \; ExecStartPre=/usr/bin/find /var/lib/spamassassin/ -type f -exec /bin/chmod 0644 "{}" \; ExecStart=/usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 --port=10027 ExecReload=/usr/bin/kill -HUP $MAINPID Environment="LANG=en_GB.UTF-8" User=sa-milt Group=sa-milt Nice=15 StandardOutput=null StandardError=null SyslogFacility=mail Restart=always RestartSec=1
I'm not seeing this here. You are running sa-update from it's normal cron job? Do you have a more restrictive root umask setup anywhere?
> You are running sa-update from it's normal cron job? yes, that's why it happily restarts the daemon and so triggers the find/chmod command of my systemd-unit while call "sa-update" with my typical environment don't so > Do you have a more restrictive root umask setup anywhere? pretty sure, hardened server environments 0027 except httpd with enforces group write and no access for "others"
(In reply to Harald Reindl from comment #2) > > Do you have a more restrictive root umask setup anywhere? > > pretty sure, hardened server environments > 0027 except httpd with enforces group write and no access for "others" Well then, there you go. From 'man sa-update': "The program sa-update uses the underlying operating system umask for the updated rule files it installs. " You could set the umask back in the cron job before calling it I suppose...