What is likely happening is that sa-learn is running as root, with nobody's permissions since apache su's itself to nobody by default on RH 9/FC1 (I am assuming this version of linux from the LC_ALL/LANG issue, although mac osx is a possibility). When you click the link in horde, it is executing that code ('/usr/local/bin/sa-learn --spam') as the user that the webserver is running under (nobody), not the user you are logged into horde with (sahil?). Therfore, you are not actually learning against the user's (sahil) bayes db. When apache su's to nobody, it looses rights to root's resources but su is notorius for not fully assuming the su'd (nobody) persona. Part of that is intentional, part of it is not. That is why sa-learn is picking up root's id as the one to try and run under but fails to have the required perms to accomplish anything. Oh yeah, I forgot to elucidate that sa-learn figures out the .spamassassin directory from the currently logged in user's home dir as reported by the env vars. Those are effected by su'ing to a new user. One example is that the 2.6X versions do not run properly under sudo but do under su. The reason, although I have never looked into it directly, are likely the difference between the behavior of su and sudo in how they set env variables.
Possible fixes:
1) don't use hordes reporting util (recommended)
2) run the webserver as root and use the command ('su -c /usr/local/bin/sa-learn --spam $user' or something like it. Do man su or su --help for more info) where $user is horde's global variable for the currently logged on user. (*NOT* recommended. Major security issues there)
3) attempt to run the command from 2 under the su'd nobody user. It may work since sometimes su is broken depending on your build of perl, etc (although it has been 6 months since I used RH, I do not believe their stock perl build was broken). It may revert to the parent processes rights instead of seeing nobody and su without a password needed. This is highly unlikely of working but it is worth a shot. It will take no time to try and can't hurt if it works. Since if it works, you have bigger problems that you can do little to fix. Although I stress, I do not think it will work.
I hope that helps,
Tom


Sahil Tandon wrote:

I understand my problem might be rooted in Horde, amavisd-new, or Postfix. However, I want to be sure it's not a fundamental misunderstanding (on my part) of how SA should be setup.

Postfix filters mail via amavisd-new (which calls SA). Everything runs smoothly except the "Report as Spam" link for users viewing messages via webmail. When clicked, it successfully sends a message to postmaster, and unsuccessfully calls sa-learn. This is what I see in my logs (sorry for line wraps):

lock: 94539 cannot create tmp lockfile /root/.spamassassin/bayes.lock.sphinx.hamla.org.94539 for /root/.spamassassin/bayes.lock: Permission denied
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
bayes expire_old_tokens: lock: 95562 cannot create tmp lockfile /root/.spamassassin/bayes.lock.sphinx.hamla.org.95562 for /root/.spamassassin/bayes.lock: Permission denied


lock: 95562 cannot create tmp lockfile /root/.spamassassin/bayes.lock.sphinx.hamla.org.95562 for /root/.spamassassin/bayes.lock: Permission denied

The relevant line in my IMP conf.php:

$conf['spam']['program'] = '/usr/local/bin/sa-learn --spam';

I googled for the error but cannot find a proper solution. Right now, /root/.spamassassin is a symlink to /var/amavis/.spamassassin; the files therein (i.e. the bayes_* files) are chown'd vscan:vscan. They are updated when SA *itself* notices spam above a certain threshold, rejects those messages, and auto-learns their spammy existence.

How to get 'sa-learn --spam' from webmail to co-exist peacefully with my current setup?

--
Sahil Tandon




Reply via email to