Spamassassin emails have wrong perms -- CC'ed to selinux list

Justin Willmert justin at jdjlab.com
Wed Feb 1 23:12:46 UTC 2006


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




More information about the fedora-selinux-list mailing list