Thanks Paul and Daniel:
My procmail invocation is:
:0fw * < 256000 | /usr/bin/spamassassin
And I see that I'm missing the lock (:) on this one, so I think my comment about procmail writing a lockfile was in error. I looked into spamc as an alternative - seems to work without a problem. Thanks for the tip Paul.
The OS is Fedora Core 5, which I've been (somewhat blindly) updating with yum (no extra configuration on yum - just running it out of the box). Yum never complained, so I did not suspect that the system was partially upgraded. To be explicit, I've not yet tried to upgrade to FC6 or FC7. For the record, current status is
[root@parsnip ~]# rpm -qa | grep policy selinux-policy-2.3.7-2.fc5 selinux-policy-targeted-2.3.7-2.fc5 policycoreutils-1.30.10-2.fc5
I guess the urgency on this is pretty low now that I've got the filter up and running (via spamc). But I'm still curious as to what I would have to have done if spamc didn't exist. I'm concerned about how many more SELinux bullets I can dodge... :)
I'm rather green, and have had some trouble deciphering a lot of the SELinux stuff. Any help would be great. I'm using procmail to filter mail through spamassassin (SA), but SELinux appears to be interfering. I say this because if I turn off enforcing, mail gets through properly tagged by SA. With SELinux on, messages are not tagged by SA. The log looks like this:
Jun 26 23:07:51 parsnip kernel: audit(1182917271.036:1779): enforcing=1 old_enforcing=0 auid=4294967295 Jun 26 23:07:51 parsnip dbus: avc: received setenforce notice (enforcing=1) Jun 26 23:08:04 parsnip kernel: audit(1182917284.795:1780): avc: denied { search } for pid=28116 comm="spamassassin" name="tmp" dev=sda3 ino=26738689 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
My (rather ignorant) read is that procmail_t and tmp_t are not matching (procmail does try to write a lockfile). And what I have gleaned is that I either need some sort of rule that somehow matches these two, or I need to change some tags (on my /tmp directory?) to allow this to proceed.
Am I anywhere near the ballpark? I tried audit2why to decipher this, but it complained that it didn't understand policies outside of the range 15-20. Audit2allow returns
allow procmail_t tmp_t:di search;But I'm not sure what to do with it...
Thanks in advance for any help!
- Lowell