Re: tie failed
Feb 21 22:26:10 Luke spamd[5590]: spamd: setuid to elizabeth succeeded Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied 1) are you using bayes_path ? 2) have you set bayes_file_mode 0777 in your local.cf? YES YES If you use bayes_path in a multi-user environment, you *MUST* set bayes_file_mode 0777 in local.cf. Also, make sure that /var/.spamassassin has world rwx privileges. Thanks Matt, but it's critical to note that it only happens SOMETIMES. For example, the headers on your message to me included the expected line: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,TW_RW autolearn=ham version=3.1.7 My spam is being detected and the headers have the appropriate Bayes lines, BUT when watching the mail log, I saw an occasional tie failed message. I don't see how it could be a permissions issue if it's intermittent? THANKS - John
Re: tie failed
- Original Message - From: David Morton [EMAIL PROTECTED] To: Jim Knuth [EMAIL PROTECTED] Cc: John Fleming [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, February 22, 2007 2:03 AM Subject: Re: tie failed Could someone please translate this to n00bese with helpful suggestions/comments? It doesn't happen with all messages. I just noticed this while tailing the mail log. THANKS - John Feb 21 22:26:10 Luke spamd[5590]: spamd: setuid to elizabeth succeeded Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied That path looks fishy to me too, does user elizabeth have a valid home directory? YES. As a newbie, I need to know exactly what the tie failed msg means and when did it fail? IOW, is the issue that Bayes cannot be utilized for determining if a msg is spam, or does that part work OK but tokens cannot be written in the autolearn process? IOW, my Bayes is detecting the spam properly[at least most of the time]: X-Spam-Status: Yes, score=136.7 required=5.0 tests=BAYES_99,DNS_FROM_RFC_POST, FORGED_RCVD_HELO,FROM_HAS_MIXED_NUMS,MSGID_FROM_MTA_ID, RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E4_51_100, RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET, SARE_SUB_CASH_CHAR,SARE_SUB_ENC_ISO2022JP,URIBL_AB_SURBL,URIBL_BLACK, URIBL_JP_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=spam version=3.1.7 (And it says it autolearned, so maybe this is just one of the ones that worked OK??) I also see an occasional message header that includes autolean=unavailable - It that what ends up in the messages where the tie fails?? I don't get the intermittent nature of this. Thanks - John
Re: tie failed
David Morton wrote: Matt Kettler wrote: Also, make sure that /var/.spamassassin has world rwx privileges. Doesn't this create a potential or real giant type security risk? Well, regardless, the current user SA is running as has to be able to read and write to the bayes DB. It has to write to the journal publish atime updates at the very least. It will also want to be able to perform autolearning, journal sync, and oportunistic expiry, unless you've disabled those. Without that, bayes cannot function. Does it have a security risk? Yes, there's the possibility of someone exploiting it for local-user privilege escalation. AFAIK, SA's bayes code is very careful about how it accesses files to mitigate this risk, but there's always room for mistakes. The point is that no one should be writing directly to /var/ like that, by most filesystem standards it should be /var/*something*/.spamassassin, maybe /var/lib/spamassassin, or /var/spool/spamassassin/ or since the user bound as user elizabeth, maybe /home/elizabeth ?? but /var is not right. Erm, you do realize .spamassassin is a DIRECTORY, not a file, right? How is /var/*something*/.spamassassin/bayes_toks different from /var/.spamassassin/bayes_toks? I'd agree with you on style points, but from a security perspective there's no difference.
Re: tie failed
John Fleming wrote: I also see an occasional message header that includes autolean=unavailable - It that what ends up in the messages where the tie fails?? I don't get the intermittent nature of this. Yes. Learning is slow. If two spamd children try to learn at the same time only one will get a lock to write to the database. The child who doesn't get the lock (tie fails) will report that autolearn is unavailable. Daryl
Re: tie failed
On Thu, 22 Feb 2007, Daryl C. W. O'Shea wrote:
John Fleming wrote:
I also see an occasional message header that includes
autolean=unavailable - It that what ends up in the messages where the
tie fails?? I don't get the intermittent nature of this.
Yes. Learning is slow. If two spamd children try to learn at the same
time only one will get a lock to write to the database. The child who
doesn't get the lock (tie fails) will report that autolearn is unavailable.
But doesn't bayes_learn_to_journal help this?
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: tie failed
David B Funk wrote: On Thu, 22 Feb 2007, Daryl C. W. O'Shea wrote: John Fleming wrote: I also see an occasional message header that includes autolean=unavailable - It that what ends up in the messages where the tie fails?? I don't get the intermittent nature of this. Yes. Learning is slow. If two spamd children try to learn at the same time only one will get a lock to write to the database. The child who doesn't get the lock (tie fails) will report that autolearn is unavailable. But doesn't bayes_learn_to_journal help this? If he enabled it, sure, it'd help reduce the frequency that this occurs. There's still only a single journal, though, so it's still possible that a spamd child process won't get a tie on it during busy periods. Daryl
Re: tie failed
On Thu, 22 Feb 2007, Daryl C. W. O'Shea wrote:
David B Funk wrote:
On Thu, 22 Feb 2007, Daryl C. W. O'Shea wrote:
Yes. Learning is slow. If two spamd children try to learn at the same
time only one will get a lock to write to the database. The child who
doesn't get the lock (tie fails) will report that autolearn is unavailable.
But doesn't bayes_learn_to_journal help this?
If he enabled it, sure, it'd help reduce the frequency that this occurs.
There's still only a single journal, though, so it's still possible
that a spamd child process won't get a tie on it during busy periods.
Hmm, as the journal file is an append-only write I had assumed that
it didn't need locking, thus theoretically simultaneous updates
could be possible.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: tie failed
On Thu, Feb 22, 2007 at 03:30:24PM -0500, Daryl C. W. O'Shea wrote: If he enabled it, sure, it'd help reduce the frequency that this occurs. There's still only a single journal, though, so it's still possible that a spamd child process won't get a tie on it during busy periods. The journal has no locking, nor is it tie()'ed, it's just an open(). fyi. -- Randomly Selected Tagline: Leela: Okay, this has gotta stop. I'm going to remind Fry of his humanity the way only a woman can. Professor: You're going to do his laundry? pgpsxKvvUER9w.pgp Description: PGP signature
Re: tie failed
David B Funk wrote: On Thu, 22 Feb 2007, Daryl C. W. O'Shea wrote: David B Funk wrote: On Thu, 22 Feb 2007, Daryl C. W. O'Shea wrote: Yes. Learning is slow. If two spamd children try to learn at the same time only one will get a lock to write to the database. The child who doesn't get the lock (tie fails) will report that autolearn is unavailable. But doesn't bayes_learn_to_journal help this? If he enabled it, sure, it'd help reduce the frequency that this occurs. There's still only a single journal, though, so it's still possible that a spamd child process won't get a tie on it during busy periods. Hmm, as the journal file is an append-only write I had assumed that it didn't need locking, thus theoretically simultaneous updates could be possible. Yeah... I had (hopefully temporarily) envisioned a pretty retarded journaling method. Like Theo pointed out, there's no locking the journal. I plead sleep deprivation. Daryl
Re: tie failed
Heute (22.02.2007/04:31 Uhr) schrieb John Fleming, Could someone please translate this to n00bese with helpful suggestions/comments? It doesn't happen with all messages. I just noticed this while tailing the mail log. THANKS - John Feb 21 22:26:10 Luke spamd[5590]: spamd: setuid to elizabeth succeeded Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied Feb 21 22:26:10 Luke spamd[5590]: spamd: processing message [EMAIL PROTECTED] for elizabeth:1006 Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied ^^ Feb 21 22:26:10 Luke postfix/smtpd[6346]: disconnect from somedomain.com[204.16.32.68] Feb 21 22:26:22 Luke spamd[5590]: spamd: clean message (1.5/5.0) for elizabeth:1006 in 12.3 seconds, 2567 bytes. You do not seen? Check your permissions. -- Viele Gruesse, Kind regards, Jim Knuth [EMAIL PROTECTED] ICQ #277289867 -- Zufalls-Zitat -- Das letzte Wort des Anstreichers: Aber sicher ist das Gerüst stabil. -- Der Text hat nichts mit dem Empfaenger der Mail zu tun -- Virus free. Checked by NOD32 Version 2074 Build 9119 21.02.2007
Re: tie failed
John Fleming wrote: Could someone please translate this to n00bese with helpful suggestions/comments? It doesn't happen with all messages. I just noticed this while tailing the mail log. THANKS - John Feb 21 22:26:10 Luke spamd[5590]: spamd: setuid to elizabeth succeeded Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied 1) are you using bayes_path ? 2) have you set bayes_file_mode 0777 in your local.cf? If you use bayes_path in a multi-user environment, you *MUST* set bayes_file_mode 0777 in local.cf. Also, make sure that /var/.spamassassin has world rwx privileges.
RE: tie failed
1) are you using bayes_path ? 2) have you set bayes_file_mode 0777 in your local.cf? If you use bayes_path in a multi-user environment, you *MUST* set bayes_file_mode 0777 in local.cf. Also, make sure that /var/.spamassassin has world rwx privileges. Doesn't this create a potential or real giant type security risk? - rh -- Robert - Abba Communications Computer Internet Services (509) 624-7159 - www.abbacomm.net
Re: tie failed
R Lists06 wrote: 1) are you using bayes_path ? 2) have you set bayes_file_mode 0777 in your local.cf? If you use bayes_path in a multi-user environment, you *MUST* set bayes_file_mode 0777 in local.cf. Also, make sure that /var/.spamassassin has world rwx privileges. Doesn't this create a potential or real giant type security risk? Well, regardless, the current user SA is running as has to be able to read and write to the bayes DB. It has to write to the journal publish atime updates at the very least. It will also want to be able to perform autolearning, journal sync, and oportunistic expiry, unless you've disabled those. Without that, bayes cannot function. Does it have a security risk? Yes, there's the possibility of someone exploiting it for local-user privilege escalation. AFAIK, SA's bayes code is very careful about how it accesses files to mitigate this risk, but there's always room for mistakes. Really, using a SQL based bayes is a much better idea for an environment using a single bayes DB with multiple users accessing it. It's safer in this regard, and significantly faster too.
Re: tie failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Knuth wrote: Heute (22.02.2007/04:31 Uhr) schrieb John Fleming, Could someone please translate this to n00bese with helpful suggestions/comments? It doesn't happen with all messages. I just noticed this while tailing the mail log. THANKS - John Feb 21 22:26:10 Luke spamd[5590]: spamd: setuid to elizabeth succeeded Feb 21 22:26:10 Luke spamd[5590]: bayes: cannot open bayes databases /var/.spamassassin/bayes_* R/O: tie failed: Permission denied That path looks fishy to me too, does user elizabeth have a valid home directory? - -- David Morton Maia Mailguard- http://www.maiamailguard.com Morton Software Design and Consulting - http://www.dgrmm.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3UBcUy30ODPkzl0RAiBSAJ93qiphCb9RR93zueCwJyuVpBmB3QCfXSL/ pL5pJ6SKyyLj1uP1MfhngDU= =yNYa -END PGP SIGNATURE-
Re: tie failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Kettler wrote: Also, make sure that /var/.spamassassin has world rwx privileges. Doesn't this create a potential or real giant type security risk? Well, regardless, the current user SA is running as has to be able to read and write to the bayes DB. It has to write to the journal publish atime updates at the very least. It will also want to be able to perform autolearning, journal sync, and oportunistic expiry, unless you've disabled those. Without that, bayes cannot function. Does it have a security risk? Yes, there's the possibility of someone exploiting it for local-user privilege escalation. AFAIK, SA's bayes code is very careful about how it accesses files to mitigate this risk, but there's always room for mistakes. The point is that no one should be writing directly to /var/ like that, by most filesystem standards it should be /var/*something*/.spamassassin, maybe /var/lib/spamassassin, or /var/spool/spamassassin/ or since the user bound as user elizabeth, maybe /home/elizabeth ?? but /var is not right. - -- David Morton Maia Mailguard- http://www.maiamailguard.com Morton Software Design and Consulting - http://www.dgrmm.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3UHHUy30ODPkzl0RAsmrAKCaD5VxMMRa1XsUOeIBHC+qMgm9gACcCL9m 5T1UbPdX8AvTAyjEfTVPR7Q= =/0KG -END PGP SIGNATURE-
