George wrote:
> *trim*
>
>> If the socket is *really* created as root:wheel that could create a
>> problem.
>>
>> But the ...-u amavisd ... indicates it is being created wuth EUID:EGID
>> of amavisd:<some non-wheel group>
>
>
> amavisd:amavisd (it has it's own group)
>
>>
>> Try an ls -lF on /temp/spamd/*. to confirm.
>
>
>
> /tmp/spamd is the socket file...
>
> srw-rw-rw- 1 root wheel 0 Dec 9 12:50 /tmp/spamd=
>
>>
>>>>
>>>> - might either be leaving the socket set with ownership and/or perm
>>>> settings that block the other?
OK. Your privilege mask does allow rw to all user and groups.
Not necessarily optimal, but seems safe enough on a socket vs the stack.
>>>
>>> No. Upon the next call it works.
>>
>>
>> That is exactly why I am suspicious that there is a point during which
>> the socket is being accessed and locked by some process with higher
>> priv levels, then released again.
>
>
> I've captured two messages in debug on spamd upon a fresh start of which
> the first one immediately showed up in the exim panic log and second was
> processed with no problem. So I guess it's the message that triggers
> something.
>
> 2005-12-09 13:42:12 IR92YC-0007MF-2Z spam acl condition: Resource
> temporarily unavailable on spamd socket
ACK. While it looks as if something is there 'ahead of it' when that
triggers,
I suspect that 'execute' as well as 'rw' is needed at startup as the
daemon runing as amavisd:amavisd tries to remove old and create new
socket, (as is normally done - think about invocation after abnormal
system shutdown/restart...).
This would be blocked by prior presence of the socket with root:wheel
ownership.
What happens if you create the socket in the first place as owned by
amavisd:amavisd?
And/or (temporarily) grant 'x' as well as 'rw' to all comers for
testing? (not otherwise a good idea...)
>
> Here is the detail log for the 2 messages: captainnet.net/spamd_details.txt
>
> *trim*
>
>>> I looked in crash logs, reporters, system logs not a trace other than
>>> in the panic log and mail log.
>>>
>>
>> Usually shows up in /var/log/exim/paniclog, /var/log/maillog,
>> /var/log/messages and/or /var/log/console.log
>
>
> I couldn't find anything else that would point to the problem.
>
>
> *trim*
>
>>> During data acl
>>>
>>> warn message = X-Spam-Status: $spam_report\n\
>>> X-New-Subject: [***SPAM***] $h_subject:
>>> condition = ${if <{$message_size}{80k}{1}{0}}
>>> spam = $acl_m0:true
>>>
>>
>> Where you have 'acl_m0:true', many Exim examples have 'nobody:true',
>> and I use 'spamd:true'
>
>
> acl_m0:true compares user name in mysql which is the users full email
> address, however, I run SA only on a "per domain" basis, so "spamd:true"
> would only allow me system wide settings. That works out fine, as there
> is no message rejection. SA tags are used to filter the messages.
>
SA has its own mechanism(s) for per-domain or per-user settings.
Those too can be ~SQL-driven, and might provide a less problematic solution.
>>
>> Logs will show spamd made the run as user {number} for whomever that
>> user is.
>>
>> That is where I would look - see if acl_m0 "sometimes" furnishes a
>> non-existent system user, or one that has no rights to the socket.
>>
>> Adding:
>>
>> logwrite = spamd invoked by users $acl_m0
>
>
> It shows up in mail.log anyway, but I'll do some tests later on to compare.
>
ACK - but appears in that log only when spamd is actually invoked.
> George
>
>>
>> - to that acl will log it in mainlog (at least).
Whereas a 'logwrite' instead of log_message will log what the user
*would have have been*
even in the instances where the acl is being bypassed and spamd has not
been invoked
(unless a prior 'accept' has an 'endpass', or a deny/drop/discard verb
has already been triggered).
Noisy, as far as extra log entries, but potentially useful on a
temporary basis to narrow-down the problem point, as it can also show
you if 'overlap' calls are occuring on the same message and with
different EUID (IOW - what happens if/as/when MySQL returns no useful
UID? Or returns more than one? Or a flag instead of a string?).
BTW - I don't need a 'cc:' - it is giving me two copies of your notes...
HTH,
Bill Hacker
