On 2025-05-12 at 14:20:02 UTC-0400 (Mon, 12 May 2025 19:20:02 +0100)
Nix <n...@esperi.org.uk>
is rumored to have said:
> On 1 May 2025, Bill Cole told this:
>
>> On 2025-05-01 at 16:03:21 UTC-0400 (Thu, 01 May 2025 20:03:21 +0000)
>> Michael Grant via users <mgr...@grant.org>
>> is rumored to have said:
>>
>>> I'm seeing this error over and over in my logs over the last few weeks:
>>>
>>> spamd: 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 "" to disable queries)
>>>
>>> I did try to disable this in root's local.cf but the error continues.
>>
>> Did you do that in the "global" config at /etc/mail/spamassassin/local.cf
>> (or something like it with 'etc' somewhere) or in root's
>> user config in /root/.spamassassin/{userprefs,local.cf,whatever} ? If it was
>> the latter, you need to move it to the global config.
>>
>> OR, double-check your config line. it needs to precisely match the quoted
>> string. Note that if your mail server is using
>> SpamAssassin via the 'spamd' daemon, you should restart spamd after making
>> configuration changes. That is also true for milters like
>> MIMEDefang or MailMunge which have persistent daemons.
>
> Well... yes, only my spamd installation saw constant complaints (no
> persisting of the dnsblock config) until I chowned
> /etc/mail/spamassassin/helpers/.spamassassin/ to 1777. Look:
>
> drwxrwxrwt 2 root root 130 May 12 19:16 .
> drwxr-xr-x 4 root root 53 Jul 7 2024 ..
> -rw-r--r-- 1 nix users 0 May 12 19:16 dnsblock_bl.score.senderscore.com
> -rw-r--r-- 1 nix users 0 May 12 19:16 dnsblock_sa-accredit.habeas.com
> -rw-r--r-- 1 nix users 0 May 12 19:16 dnsblock_sa-trusted.bondedsender.org
>
> It looks like (trunk) spamd is creating the block entries in the
> systemwide dir, but doing it after setuiding to the per-mail-user UID!
> This is... unlikely to work unless you make the helper/.spamassassin dir
> 1777 (as above), which feels... extremely wrong.
I might quibble with "extremely" but, yes. The sticky bit is doing important
work there. I hope that others who have per-user checking set up have not
'solved' this with a simple 0777. Making the directory 1775 root:users is
arguably slightly better.
I'm not entirely sure how that gets fixed, but we definitely should fix it. The
basic issue is that by the time we are doing any work with rules (which may be
user-defined) we have handed the spamc connection to a child spamd process
running as the recipient. In principle, we should treat anything that child
does as tainted by default and only allow the child to change global config
with very tight supervision.
--
Bill Cole
