[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]