~/.spamassassin on toucan: -rw-rw---- 1 spamd spamd 2650112 Oct 2 10:45 auto-whitelist -rw------- 1 spamd spamd 3408 Oct 2 10:45 bayes_journal -rw-rw---- 1 slarti spamd 663552 Oct 2 10:07 bayes_seen -rw------- 1 spamd spamd 5079040 Oct 2 10:07 bayes_toks -rw-rw---- 1 slarti spamd 1173 Sep 26 17:15 user_prefs My local ~/.spamassassin, similar setup, using spamd: -rw------- 1 tmartin users 151552 Sep 3 21:05 auto-whitelist -rw------- 1 tmartin users 663552 Sep 25 18:01 bayes_seen -rw------- 1 tmartin users 5263360 Sep 25 18:01 bayes_toks -rw------- 1 tmartin users 1175 May 15 09:29 user_prefs And, when using sa-learn: slarti@toucan new % sa-learn --spam 1128247202.8514_0.toucan Cannot open bayes databases /home/slarti/.spamassassin/bayes_* R/O: tie failed: Permission denied Cannot open bayes databases /home/slarti/.spamassassin/bayes_* R/W: tie failed: Permission denied Cannot open bayes databases /home/slarti/.spamassassin/bayes_* R/W: tie failed: Permission denied Cannot open bayes databases /home/slarti/.spamassassin/bayes_* R/W: tie failed: Permission denied Learned from 0 message(s) (1 message(s) examined). ERROR: the Bayes learn function returned an error, please re-run with -D for more information lcars said on IRC that he'd be looking into this. Thanks, Tom
Tom, shot in the dark, but try this: (make a backup copy of your bayes files first) db4.2_upgrade bayes_seen db4.2_upgrade bayes_toks -C
This is the whole problem. I *can't* backup my bayes_toks, bayes_journal or auto-whitelist because I don't own them or have read to them. I can't db4.2_upgrade bayes_toks because I don't even have read permission, let alone write.
I got bit by this too. Had too rm the contents of .spamassassin just to stop the mailing list program bouncing my mails every 2 hours :/
Folks any suggestions? I don't want to manually chown the files and I don't see any umask/perms setting for spamd -c option. I'm no SA guru so help is appreciated.
I'll try and take a look at this today.
*** Bug 115768 has been marked as a duplicate of this bug. ***
I believe the original issue was solar being uneasy about having spamd running sa setuid, but I'm not sure. Let me try and get him to comment on this bug.
I dont recall that being the case lance. But now that you bring it up, yeah I'm anti having setXid perl scripts. spamd was a bonus feature provided by infra. If you want better filtering sadly I think you should probably do that in your client till a solution exists that does not require us to add new setXid's
If spamassasin is weird, I'd say maybe go with bogofilter: http://bogofilter.sourceforge.net/ and no, I'm not going to just say, "Hey, let's use bogofilter when some of our devs might not know how to use it", so I made a doc: http://dev.gentoo.org/~chriswhite/docs/bogofilter.html http://dev.gentoo.org/~chriswhite/xml_sources/bogofilter.xml This should cover the basic stuff that most devs will need to control spam using bogofilter.
(In reply to comment #9) > If spamassasin is weird, I'd say maybe go with bogofilter: It's not that simple. One of the reasons SA was chosen for toucan was that it has a central spam daemon that could really reduce resource usage. In addition, it provides rule-based filtering as well as Bayesian filtering, something which bogofilter doesn't do. Switching to bogofilter would mean there would essentially be no filtering at all until everyone trains up their wordlist. The flood of spam into everyone's inboxes over this initial period would be mammoth, amongst other problems. I'm not sure exactly what we can do now, to be honest. For people using IMAP, client-side spam filtering is tricky, to say the least. Even with offlineimap, I'm not sure how it could be implemented, besides forcing everyone to use Evolution or Thunderbird. Maybe an email to a spamassassin list or an excursion to their IRC channel will yield some results :)
Well, if someone wants to outline the exact result they'd like as far as permissions/etc, I'm willing to tear spamassasin apart and make a patch to implement these changes. I have lots of new spammers as of recently, and I'd like to be able to train sa on them.
(In reply to comment #11) > Well, if someone wants to outline the exact result they'd like as far as > permissions/etc, I'm willing to tear spamassasin apart and make a patch to > implement these changes. The target permissions are outlined in the initial bug report. To summarise: - lcars can't figure out why they're like that, and doesn't feel comfortable with manual chmoding. - cshields thinks it's related to a berkdb upgrade, but this is unverifiable. - Ramereth thinks it's because solar didn't want any setXid perl scripts on toucan. - solar doesn't recall this being the case, but agrees anyway.
Well, it gets weird.. it's not the normal behaviour of sa to do that apparently. I think this was a one time only hickup as: sa-learn --dbpath=~/sa_db --spam 1134737421.29187_0.toucan:2, learns the file and stuffs it: -rw------- 1 chriswhite users 12288 Dec 17 21:29 /home/chriswhite/sa_db_seen -rw------- 1 chriswhite users 49152 Dec 17 21:29 /home/chriswhite/sa_db_toks however, this much still comes out: bayes: cannot open bayes databases /home/chriswhite/.spamassassin/bayes_* R/O: tie failed: Permission denied Though interestingly enough it does that, then goes through with the sa_db_* files just nicely. It appears to umask the db's as such: oct($main->{conf}->{bayes_file_mode}) & 0666 so another question is what bayes_file_mode is set for. This is all I could find, nothing directly seems to chmod anything.
Just an FYI, cfengine sets these permissions, not SA. We did that to get around the orginal issue (which I can't quite remember what it was). But I thought it was a setuid issue. I might look into this more tonight.
Ok, I remember now what the issue was. By default, spamd runs as root which will allow it to set it's uid to the user to write user pref files and such. We didn't want to do that, so we opted to using a non-root user (spamd), but doing that disallowed spamd from writing/reading user pref files. From the docs [1]: System-Level Security --------------------- spamd has the facility to run as a non-root user, this has potential security payoffs. If a fault is found in spamd or spamassassin code, any third party linked-libraries or imported perl modules there is the potential for abuse of both the running uid of spamd, and the uid of the username supplied by spamc (and this could be any user). When run as root, spamd will change uid's to the user invoking spamc in order to read and write to their configurations. This functionality is not possible if spamd does not run as root and is a disadvantage if you rely on this. If you use mysql or LDAP for per-user configuration there is no reason in the world to run as root, and this remains fully functional. If you do not need to let your users define their own rules, maintain their own whitelists, or have non-world-readable home and ~/.spamassassin directories, then just set spamd up to run with the "-u username" option. Since spamd can use auto-whitelisting, which requires it maintain a database of email addresses on-disk, you should use a non-"root" but non-"nobody" user: "mailnull" or "mail" are good choices, or even create a "spamd" user. ------ I think the best solution right now is either using LDAP to store this information, or use a mysql database. Let me try and get lcars to reply to this to see what he thinks. [1] http://wiki.apache.org/spamassassin/BetterDocumentation/SpamdReadme
Ok we can so SA <> LDAP fairly easily and it looks clean enough. My only concern is performance but the only way to find out is testing it. I'll set this up when I get the chance.
Okay, removing bayes_* and auto-whitelist, training, then making them -rw-rw---- slarti:spamd solves the problem, for anyone who needs it now. (Thanks hparker). Not sure how to make this into a permanent fix though.
(In reply to comment #17) > > Not sure how to make this into a permanent fix though. > Said without reading the above comments, of course ;) Never mind.
Closing since we have global bayes working on woodpecker now.
(In reply to comment #19) > Closing since we have global bayes working on woodpecker now. slarti@woodpecker cur % sa-learn --spam --showdots * bayes: locker: safe_lock: cannot create tmp lockfile /var/amavis/.spamassassin/bayes.lock.woodpecker.gentoo.org.15402 for /var/amavis/.spamassassin/bayes.lock: Permission denied config: cannot open "/etc/mail/spamassassin/secrets.cf": Permission denied bayes: expire_old_tokens: locker: safe_lock: cannot create tmp lockfile /var/amavis/.spamassassin/bayes.lock.woodpecker.gentoo.org.30809 for /var/amavis/.spamassassin/bayes.lock: Permission denied Learned tokens from 0 message(s) (1 message(s) examined) There are 219 messages in that directory. Not sure exactly what's going on...
we don't offer per-user bayesian training.
