I said I'd post my final results, so here they are. All these problems
are describing spamd and not the spamassassin program on FC4. The
problems only affect spamd because it is subject to selinux policy
effects where spamassassin (run by a user) isn't (at least in the
targeted policy).
My first problem was with emails being owned by root instead of the
correct user. I am using /etc/procmailrc rather than ~/.procmailrc, so
it would by default be under root permissions. I added the line
'DROPPRIV=yes' to make it have user permissions instead, but I mistyped
it. It should be 'DROPPRIVS=yes'. *Notice the added S*. That was all
there was to that problem. Human error.
Next, I set up spamassassin to share a common bayes database. Even with
nobody(99) owning it (that's what spamassassin would setuid to after
failing to setuid to the user. More on that below...), I still couldn't
write to the database. After looking through the selinux policy source
files for spamassassin (you can surprisingly learn a lot just by looking
through those files...), I found that the bayes files should probably
have a user_home_t context, and the folder they reside in, a context of
user_home_dir_t (which makes sense considering they're normally found in
a user's home directory). After I had set /etc/mail/bayes/ (the folder I
chose to house my bayes files) and it's contents to those contexts, I
got rid of that problem.
Now for the user problems. All the users on my system are setup in an
LDAP directory. My system uses nsswitch.conf mechanisms (set with the
authconfig utility), so when spamd went to connect to the ldap server
(indirectly through normal linux authentication libraries which behind
the scenes connect to the ldap server. Programmers should understand
this logic.), selinux would deny access because spamd doesn't have
ldap_port_t permissions (or in layman's terms, spamd wasn't allowed to
connect to any port but tcp port 783 which is spamd's command port). As
of selinux-policy-targeted-1.27.1-2.16, there isn't a fix, but Dan Walsh
has told me that he has put it in the rawhide and I've posted a bugzilla
report about it, so there should be a fix soon. A perfectly OK temporary
fix is to just use the spamassassin executable in your procmail scripts
rather than using spamc to communicate to spamd. That's what I'm doing
right now and it is working fine (with some performance loss because of
program load/unload times, etc).
Thanks to all those who have helped.
Justin Willmert
