You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Gene Heskett <ge...@verizon.net> on 2005/03/24 04:18:02 UTC

New SA-3.0.2 partially barfs.

Greetings;

I did have SA-2.64 installed and was using it with kmail from the 
kde-3.3.0 install, heavily hacked FC2 system, present kernel 
2.6.12-rc1-mm1.

This had generated a series of files in /root/.spamassassin including 
a bayes_journal, which after about a years running, was only expanded 
to about 2700 bytes.

After setting spamd to be run from /etc/init.d, using the options 
in /etc/sysconfig/spamassassin of:
----------------
# Options to spamd
SPAMDOPTIONS="-d -c -m10 -H"
----------------

which are the defaults apparently, and changing kmails filter for the 
spam disposal so it was piped thru spamc, it ran and filtered about 
20 spams properly over the next 20 minutes.

Then I suddenly start seeing this in the /var/log/maillog:
----------------
Mar 23 21:49:26 coyote spamd[21906]: connection from 
localhost.localdomain [127.0.0.1] at port 46232
Mar 23 21:49:26 coyote spamd[21906]: info: setuid to root succeeded
Mar 23 21:49:26 coyote spamd[21906]: Still running as root: user not 
specified with -u, not found, or set to root.  Fall back to nobody.
Mar 23 21:49:26 coyote spamd[21906]: processing message 
<20...@verizon.net> for root:99.
Mar 23 21:49:26 coyote spamd[21906]: cannot write 
to /root/.spamassassin/bayes_journal, Bayes db update ignored: 
Permission denied
Mar 23 21:49:26 coyote spamd[21906]: clean message (0.0/5.0) for 
root:99 in 0.2 seconds, 5182 bytes.
Mar 23 21:49:26 coyote spamd[21906]: result: .  0 - BAYES_50 
scantime=0.2,size=5182,mid=<20...@verizon.net>,bayes=0.455596022142826,autolearn=failed
----------------

FWIW, any attempt to add the --username=root to the above options file 
results in spamd failing to restart on a 'service spamd restart'.
And yes, I run as root, there is lots of firealling between this box 
and the real planetary network, firewalling thats never, in 2 years 
of dsl connection, been penetrated any farther than a single "New not 
syn: etc etc" message in the logs.  My guard dogs are good.
 
This snippet is indicating that A: it apparently cannot run as root so 
it falls back to 'nobody'

and B: that it cannot write to /root/.spamassassin/bayes_journal.

The file had disappeared!  I went back thru the shell history to make 
sure I hadn't done anything stupid, but the only thing between the 
time it worked, and the files disappearance was my looking at it with 
the 'less' file viewer.

So I touched a new one and set the perms to 0666 so it would be 
writable.

Didn't make any difference.  The other files in that directory are 
being updated if I run a session of sa-learn, but that file isn't 
being touched, and although the dates are being updated for the other 
2 main files, no content is actually being added to them by the 
sa-learn session as evidence by their unchanging size of several megs 
each.

However, it does seem to be filtering the spam as well as before after 
I updated the rules for the 2nd filter in kmail as the marker strings 
had been changed some from the 2.64 version.  Its also not marking 
the subject line [SPAM] like it did before. I'd like it to if 
possible.

From this amount of data, can it be determined whats wrong?

Any help accepted with glee & thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Thursday 24 March 2005 13:58, gallen@netrox.net wrote:

>SA does not allow running it as 'root' user. It is considered a
> security risk. SA files also should not be in 'root' user folder.
> Should be in something like /var/filter/.spamassassin  (filter
> being the name of the user)

There is ATM, nothing spamassassin related in /var.

>You need to have a user such as 'filter' run it.

I can understand that, but please note that when called by spamc, it 
does an suid to the callers ID number, in this case root because its 
root that started x and kmail, and its kmail thats trying to pipe the 
mail thru spamc.  So spamc is telling it to be root regardless.

When it then discovers its root, it does another suid to nobody 
according to the logs.  So this seems like the chain between 2 
immovable objects is still a couple of links short, and probably a 
bit long in the paranoia dept.

Running kmail as non-root is not an option, its a konstruct built kde, 
and it and qt are both installed in /root/kde3.3

>Here is a fairly good write-up.
>
>http://advosys.ca/papers/postfix-filtering.html
>
>> Why is this?  And how can I fix it?
>>
>>>and B: that it cannot write to /root/.spamassassin/bayes_journal.
>>>
>>>The file had disappeared!

Which still doesn't address this problem at all.  What did kill the 
file, and how does one regenerate it if its a fancy 'db' type file?

>>>I went back thru the shell history to
>>> make sure I hadn't done anything stupid, but the only thing
>>> between the time it worked, and the files disappearance was my
>>> looking at it with the 'less' file viewer.
>>>
>>>So I touched a new one and set the perms to 0666 so it would be
>>>writable.
>>
>> Is this some sort of a berkeleyDB file?  If so, how can I
>> regenerate it properly?
>>
>>>That didn't make any difference.  The other files in that
>>> directory are being updated if I run a session of sa-learn, but
>>> that file isn't being touched, and although the dates are being
>>> updated for the other 2 main files, no content is actually being
>>> added to them by the sa-learn session as evidence by their
>>> unchanging size of several megs each.
>>>
>>>However, it does seem to be filtering the spam as well as before
>>> after I updated the rules for the 2nd filter in kmail as the
>>> marker strings had been changed some from the 2.64 version.  Its
>>> also not marking the subject line [SPAM] like it did before. I'd
>>> like it to if possible.
>>>
>>>>>>From this amount of data, can it be determined whats wrong?
>>>
>>>Any help accepted with glee & thanks.
[...]

If I can't make 3.0.2 work while running as root, then I suppose I'll 
have to drag out the cd's and reinstall 2.6.4, which didn't have 
those restrictions.  Or learn enough perl (yeah sure, at my age) to 
patch that restriction back out of /usr/bin/spamd.  From what I've 
seen of perl, its what APL might grown up into.  Shudder.  APL should 
have been put out of its misery 30 years ago.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Monday 28 March 2005 21:20, Daryl C. W. O'Shea wrote:
>Gene Heskett wrote:
>> On Monday 28 March 2005 20:26, Daryl C. W. O'Shea wrote:
>>>bayes_file_mode
>>
>> I had that set for 0770, but the man pages says 0700 and a chmod
>> +x, so thats what it is now.  We'll see how that works.
>>
>> You'll recall from my first message that this is the file that
>> disappeared on me & started this whole session of 10,000 monkeys
>> looking for a solution.
>
>It'd have to be world r/w (0777) to do what you want to do.

I did try that while I was herding the monkeys, no effect.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Gene Heskett wrote:
> On Monday 28 March 2005 20:26, Daryl C. W. O'Shea wrote:
> 
>>bayes_file_mode
> 
> 
> I had that set for 0770, but the man pages says 0700 and a chmod +x, 
> so thats what it is now.  We'll see how that works.
> 
> You'll recall from my first message that this is the file that 
> disappeared on me & started this whole session of 10,000 monkeys 
> looking for a solution.

It'd have to be world r/w (0777) to do what you want to do.


Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Monday 28 March 2005 20:26, Daryl C. W. O'Shea wrote:
>bayes_file_mode

I had that set for 0770, but the man pages says 0700 and a chmod +x, 
so thats what it is now.  We'll see how that works.

You'll recall from my first message that this is the file that 
disappeared on me & started this whole session of 10,000 monkeys 
looking for a solution.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Gene Heskett wrote:
> On Monday 28 March 2005 15:01, Daryl C. W. O'Shea wrote:
>>
>>Gene doesn't even need to do that.  Just create another user, such
>>as 'rootsa' and call spamc with the option '-u rootsa'.  Or, if
>>you'd like a more generic or global SA bayes database/etc,
>>something like 'spamd' would be appropriate.
>>
>>There's no need to open up SA to possible exploits of modules it
>>depends on (or itself).
>>
> 
> I tried a variation on that, makeing a user 'spamd' but then it still 
> didn't have permissions to use or update the filter files.  I didn't 
> try making spamd a member of root though.  I also tried making all 
> the rules file owned by nobody:nobody but that didn't work either.
> 
> What I have done now is letting it work according to the log.  And its 
> gradually getting back in synch with the latest viagra peddlers.

You'd need to set the config option bayes_file_mode to something 
appropriate to make it work.

Daryl


Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Monday 28 March 2005 15:01, Daryl C. W. O'Shea wrote:
>Steve Prior wrote:
>> Gene Heskett wrote:
>>> The point being that under those conditions, root doesn't have
>>> any filtering.  So, I located that section of code in
>>> /usr/bin/spamd, and commented it out.  I believe its now working.
>>>  Locking root out of using a valuable tool just to try and
>>> convince that user not to run as root isn't security IMO, its
>>> excessive paranoia.  That piece of the code should be wrapped in
>>> a config file option, and then forget to document the option
>>> maybe.  In that case, someone with enough smarts to read the code
>>> can figure it out.
>>>
>>> My converting to run as other than root here would be a virtual
>>> wipe it and reinstall of a nearly 70 GB system.  Thats not going
>>> to happen barring a major hardware failure.  And I have good
>>> backups so I'd recover rather than reinstall anyway.
>>
>> Or you could simply put an alias in to redirect roots email to a
>> different userid which wouldn't have the "no root" restriction. 
>> That should be no big
>> deal.
>>
>> Steve
>
>Gene doesn't even need to do that.  Just create another user, such
> as 'rootsa' and call spamc with the option '-u rootsa'.  Or, if
> you'd like a more generic or global SA bayes database/etc,
> something like 'spamd' would be appropriate.
>
>There's no need to open up SA to possible exploits of modules it
> depends on (or itself).
>
I tried a variation on that, makeing a user 'spamd' but then it still 
didn't have permissions to use or update the filter files.  I didn't 
try making spamd a member of root though.  I also tried making all 
the rules file owned by nobody:nobody but that didn't work either.

What I have done now is letting it work according to the log.  And its 
gradually getting back in synch with the latest viagra peddlers.

>
>Daryl

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Steve Prior wrote:
> Gene Heskett wrote:
> 
>> The point being that under those conditions, root doesn't have any 
>> filtering.  So, I located that section of code in /usr/bin/spamd, and 
>> commented it out.  I believe its now working.  Locking root out of 
>> using a valuable tool just to try and convince that user not to run as 
>> root isn't security IMO, its excessive paranoia.  That piece of the 
>> code should be wrapped in a config file option, and then forget to 
>> document the option maybe.  In that case, someone with enough smarts 
>> to read the code can figure it out.
>>
>> My converting to run as other than root here would be a virtual wipe 
>> it and reinstall of a nearly 70 GB system.  Thats not going to happen 
>> barring a major hardware failure.  And I have good backups so I'd 
>> recover rather than reinstall anyway.
>>
> 
> Or you could simply put an alias in to redirect roots email to a different
> userid which wouldn't have the "no root" restriction.  That should be no 
> big
> deal.
> 
> Steve

Gene doesn't even need to do that.  Just create another user, such as 
'rootsa' and call spamc with the option '-u rootsa'.  Or, if you'd like 
a more generic or global SA bayes database/etc, something like 'spamd' 
would be appropriate.

There's no need to open up SA to possible exploits of modules it depends 
on (or itself).


Daryl


Re: New SA-3.0.2 partially barfs.

Posted by Steve Prior <sp...@geekster.com>.
Gene Heskett wrote:
> The point being that under those conditions, root doesn't have any 
> filtering.  So, I located that section of code in /usr/bin/spamd, and 
> commented it out.  I believe its now working.  Locking root out of 
> using a valuable tool just to try and convince that user not to run 
> as root isn't security IMO, its excessive paranoia.  That piece of 
> the code should be wrapped in a config file option, and then forget 
> to document the option maybe.  In that case, someone with enough 
> smarts to read the code can figure it out.
> 
> My converting to run as other than root here would be a virtual wipe 
> it and reinstall of a nearly 70 GB system.  Thats not going to happen 
> barring a major hardware failure.  And I have good backups so I'd 
> recover rather than reinstall anyway.
> 

Or you could simply put an alias in to redirect roots email to a different
userid which wouldn't have the "no root" restriction.  That should be no big
deal.

Steve

Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Thursday 24 March 2005 19:36, Gene Heskett wrote:
>On Thursday 24 March 2005 13:58, gallen@netrox.net wrote:
>>SA does not allow running it as 'root' user. It is considered a
>> security risk. SA files also should not be in 'root' user folder.
>> Should be in something like /var/filter/.spamassassin  (filter
>> being the name of the user)
>>

The point being that under those conditions, root doesn't have any 
filtering.  So, I located that section of code in /usr/bin/spamd, and 
commented it out.  I believe its now working.  Locking root out of 
using a valuable tool just to try and convince that user not to run 
as root isn't security IMO, its excessive paranoia.  That piece of 
the code should be wrapped in a config file option, and then forget 
to document the option maybe.  In that case, someone with enough 
smarts to read the code can figure it out.

My converting to run as other than root here would be a virtual wipe 
it and reinstall of a nearly 70 GB system.  Thats not going to happen 
barring a major hardware failure.  And I have good backups so I'd 
recover rather than reinstall anyway.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Thursday 24 March 2005 19:36, Gene Heskett wrote:
>On Thursday 24 March 2005 13:58, gallen@netrox.net wrote:
>>SA does not allow running it as 'root' user. It is considered a
>> security risk. SA files also should not be in 'root' user folder.
>> Should be in something like /var/filter/.spamassassin  (filter
>> being the name of the user)
>>
>>You need to have a user such as 'filter' run it.
>>
>>Here is a fairly good write-up.
>>
>>http://advosys.ca/papers/postfix-filtering.html
>
>I followed this link, and have anomy partially installed, even went
>and bought the AvpLinux package from kapersky.  Unforch the server
>link returned after my card was honored, seems to be a dead link,
>mozilla opens a new instance, and sits there forever with a blank
>screen ... ahh, that was the new firefox, lemme try mozilla.  Ok,
> its also sitting there waiting for their sites response, which
> apparently isn't going to happen.
>
>Since the link will time out in a few days, has anyone else noted
> that this is a constant problem, or is it just a network glitch? 
> If its a problem, I can cancel the card charge easily enough.  The
> question then becomes "how do I make all this anomy stuff work
> without it?"
>
>>> Why is this?  And how can I fix it?
>>>
>>>>and B: that it cannot write to /root/.spamassassin/bayes_journal.
>>>>
>>>>The file had disappeared!
>>>>
>>>>I went back thru the shell history to
>>>> make sure I hadn't done anything stupid, but the only thing
>>>> between the time it worked, and the files disappearance was my
>>>> looking at it with the 'less' file viewer.
>>>>
>>>>So I touched a new one and set the perms to 0666 so it would be
>>>>writable.
>>>
>>> Is this some sort of a berkeleyDB file?  If so, how can I
>>> regenerate it properly?
>>>
>>>>That didn't make any difference.  The other files in that
>>>> directory are being updated if I run a session of sa-learn, but
>>>> that file isn't being touched, and although the dates are being
>>>> updated for the other 2 main files, no content is actually being
>>>> added to them by the sa-learn session as evidence by their
>>>> unchanging size of several megs each.
>>>>
>>>>However, it does seem to be filtering the spam as well as before
>>>> after I updated the rules for the 2nd filter in kmail as the
>>>> marker strings had been changed some from the 2.64 version.  Its
>>>> also not marking the subject line [SPAM] like it did before. I'd
>>>> like it to if possible.
>>>>
>>>>>>>>From this amount of data, can it be determined whats wrong?
>>>>
>>>>Any help accepted with glee & thanks.

Update of sorts.  I have not yet installed the kaspersky stuff although
I finally did get it to download, about an hour short of my call
my card and cancel the charge deadline.

I'm prefering to make spamassassin work if I can.  But I cannot learn
new spam so its become an ever larger problem as the days wear on.

I've opened up the rpm for 3.0.2 with mc, and verified that
everything is properly installed, overwriting my install of the
tarball version from last week.  I've disabled the init..d/spamd
launcher in favor of the very similar spamassassin launcher thats
now used, and the spamd's are running.

Running 'spamassassin --lint' returns nothing.  Adding a -D to the
cli spits out a lot of stuff with no obvious to me errors. 

But the log messages haven't changed with each incoming message generating
this series of log entries:
Mar 28 13:30:55 coyote spamd[1616]: connection from localhost.localdomain
 [127.0.0.1] at port 40618
Mar 28 13:30:55 coyote spamd[1616]: info: setuid to root succeeded
Mar 28 13:30:55 coyote spamd[1616]: Still running as root: user not
 specified with -u, not found, or set to root.Fall back to nobody.
Mar 28 13:30:55 coyote spamd[1616]: processing message
 <71...@G131515> for root:99.
Mar 28 13:30:56 coyote spamd[1616]: cannot write to /root/.spamassassin/bayes_journal,
 Bayes db update ignored: Permission denied
Mar 28 13:30:59 coyote spamd[1616]: identified spam (9.6/5.0) for root:99
 in 3.8 seconds, 3344 bytes.
Mar 28 13:30:59 coyote spamd[1616]: result: Y  9 - BAYES_99,HELO_DYNAMIC_SPLIT_IP,
 HTML_90_100,HTML_IMAGE_ONLY_16,HTML_IMAGE_RATIO_02,HTML_MESSAGE,MPART_ALT_DIFF,
 RCVD_IN_NJABL_DUL,URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL scantime=3.8,size=3344,
 mid=<71...@G131515>,
 bayes=0.997353255786358,autolearn=no

Which I hand wrapped to improve the readability above.  It appears
to me that the problem is the fallback to the user 'nobody', who
at 99, would not have perms to write to those files since I and kmail 
are running as root.  If I run the 'spamassassin --lint' as root,
those files are successfully updated. An attempt to 'su nobody'
returns this:
[root@coyote /]# su nobody
This account is currently not available.

What can I do to restore it other than going back to SA-2.6.4?
Or jumping ship to the kaspersky stuffs?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Thursday 24 March 2005 13:58, gallen@netrox.net wrote:
>SA does not allow running it as 'root' user. It is considered a
> security risk. SA files also should not be in 'root' user folder.
> Should be in something like /var/filter/.spamassassin  (filter
> being the name of the user)
>
>You need to have a user such as 'filter' run it.
>
>Here is a fairly good write-up.
>
>http://advosys.ca/papers/postfix-filtering.html
>
I followed this link, and have anomy partially installed, even went 
and bought the AvpLinux package from kapersky.  Unforch the server 
link returned after my card was honored, seems to be a dead link, 
mozilla opens a new instance, and sits there forever with a blank 
screen ... ahh, that was the new firefox, lemme try mozilla.  Ok, its 
also sitting there waiting for their sites response, which apparently 
isn't going to happen.

Since the link will time out in a few days, has anyone else noted that 
this is a constant problem, or is it just a network glitch?  If its a 
problem, I can cancel the card charge easily enough.  The question 
then becomes "how do I make all this anomy stuff work without it?"

>> Why is this?  And how can I fix it?
>>
>>>and B: that it cannot write to /root/.spamassassin/bayes_journal.
>>>
>>>The file had disappeared!
>>>
>>>I went back thru the shell history to
>>> make sure I hadn't done anything stupid, but the only thing
>>> between the time it worked, and the files disappearance was my
>>> looking at it with the 'less' file viewer.
>>>
>>>So I touched a new one and set the perms to 0666 so it would be
>>>writable.
>>
>> Is this some sort of a berkeleyDB file?  If so, how can I
>> regenerate it properly?
>>
>>>That didn't make any difference.  The other files in that
>>> directory are being updated if I run a session of sa-learn, but
>>> that file isn't being touched, and although the dates are being
>>> updated for the other 2 main files, no content is actually being
>>> added to them by the sa-learn session as evidence by their
>>> unchanging size of several megs each.
>>>
>>>However, it does seem to be filtering the spam as well as before
>>> after I updated the rules for the 2nd filter in kmail as the
>>> marker strings had been changed some from the 2.64 version.  Its
>>> also not marking the subject line [SPAM] like it did before. I'd
>>> like it to if possible.
>>>
>>>>>>From this amount of data, can it be determined whats wrong?
>>>
>>>Any help accepted with glee & thanks.
>>
>> --
>> Cheers, Gene
>> "There are four boxes to be used in defense of liberty:
>>  soap, ballot, jury, and ammo. Please use in that order."
>> -Ed Howdershelt (Author)
>> 99.34% setiathome rank, not too shabby for a WV hillbilly
>> Yahoo.com and AOL/TW attorneys please note, additions to the above
>> message by Gene Heskett are:
>> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: New SA-3.0.2 partially barfs.

Posted by ga...@netrox.net.
SA does not allow running it as 'root' user. It is considered a security
risk. SA files also should not be in 'root' user folder. Should be in
something like /var/filter/.spamassassin  (filter being the name of the
user)

You need to have a user such as 'filter' run it.

Here is a fairly good write-up.

http://advosys.ca/papers/postfix-filtering.html





> Why is this?  And how can I fix it?
>
>>and B: that it cannot write to /root/.spamassassin/bayes_journal.
>>
>>The file had disappeared!
>
>>I went back thru the shell history to
>> make sure I hadn't done anything stupid, but the only thing between
>> the time it worked, and the files disappearance was my looking at
>> it with the 'less' file viewer.
>>
>>So I touched a new one and set the perms to 0666 so it would be
>>writable.
>
> Is this some sort of a berkeleyDB file?  If so, how can I regenerate
> it properly?
>
>>That didn't make any difference.  The other files in that directory
>>are being updated if I run a session of sa-learn, but that file
>>isn't being touched, and although the dates are being updated for
>>the other 2 main files, no content is actually being added to them
>> by the sa-learn session as evidence by their unchanging size of
>> several megs each.
>>
>>However, it does seem to be filtering the spam as well as before
>> after I updated the rules for the 2nd filter in kmail as the marker
>> strings had been changed some from the 2.64 version.  Its also not
>> marking the subject line [SPAM] like it did before. I'd like it to
>> if possible.
>>
>>>>From this amount of data, can it be determined whats wrong?
>>
>>Any help accepted with glee & thanks.
>
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 99.34% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com and AOL/TW attorneys please note, additions to the above
> message by Gene Heskett are:
> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
>


Re: New SA-3.0.2 partially barfs.

Posted by Gene Heskett <ge...@verizon.net>.
On Wednesday 23 March 2005 22:18, Gene Heskett wrote:
>Greetings;
>
Repost with some editing.

>I did have SA-2.64 installed and was using it with kmail from the
>kde-3.3.0 install, heavily hacked FC2 system, present kernel
>2.6.12-rc1-mm1.
>
>This had generated a series of files in /root/.spamassassin
> including a bayes_journal, which after about a years running, was
> only expanded to about 2700 bytes.

Trying to make the spamd/spamc combo work, I installed 3.0.2 exactly 
as the INSTALL said.
>
>After setting spamd to be run from /etc/init.d, using the options
>in /etc/sysconfig/spamassassin of:
>----------------
># Options to spamd
>SPAMDOPTIONS="-d -c -m5 -H"
>----------------
>
>which are the defaults apparently, and changing kmails filter for
> the spam disposal so it was piped thru spamc, it ran and filtered
> about 20 spams properly over the next 20 minutes.
>
>Then I suddenly start seeing this in the /var/log/maillog:
>----------------
>Mar 23 21:49:26 coyote spamd[21906]: connection from
>localhost.localdomain [127.0.0.1] at port 46232
>Mar 23 21:49:26 coyote spamd[21906]: info: setuid to root succeeded
>Mar 23 21:49:26 coyote spamd[21906]: Still running as root: user not
>specified with -u, not found, or set to root.  Fall back to nobody.
>Mar 23 21:49:26 coyote spamd[21906]: processing message
><20...@verizon.net> for root:99.
>Mar 23 21:49:26 coyote spamd[21906]: cannot write
>to /root/.spamassassin/bayes_journal, Bayes db update ignored:
>Permission denied
>Mar 23 21:49:26 coyote spamd[21906]: clean message (0.0/5.0) for
>root:99 in 0.2 seconds, 5182 bytes.
>Mar 23 21:49:26 coyote spamd[21906]: result: .  0 - BAYES_50
>scantime=0.2,size=5182,mid=<200503232143.24878.gene.heskett@verizon.
>net>,bayes=0.455596022142826,autolearn=failed ----------------
>
>FWIW, any attempt to add the --username=root to the above options
> file results in spamd failing to restart on a 'service spamd
> restart'. And yes, I run as root, there is lots of firealling
> between this box and the real planetary network, firewalling thats
> never, in 2 years of dsl connection, been penetrated any farther
> than a single "New not syn: etc etc" message in the logs.  My guard
> dogs are good.
>
>This snippet is indicating that A: it apparently cannot run as root
> so it falls back to 'nobody'

Why is this?  And how can I fix it?

>and B: that it cannot write to /root/.spamassassin/bayes_journal.
>
>The file had disappeared!

>I went back thru the shell history to 
> make sure I hadn't done anything stupid, but the only thing between
> the time it worked, and the files disappearance was my looking at
> it with the 'less' file viewer.
>
>So I touched a new one and set the perms to 0666 so it would be
>writable.

Is this some sort of a berkeleyDB file?  If so, how can I regenerate 
it properly?

>That didn't make any difference.  The other files in that directory 
>are being updated if I run a session of sa-learn, but that file 
>isn't being touched, and although the dates are being updated for 
>the other 2 main files, no content is actually being added to them 
> by the sa-learn session as evidence by their unchanging size of
> several megs each.
>
>However, it does seem to be filtering the spam as well as before
> after I updated the rules for the 2nd filter in kmail as the marker
> strings had been changed some from the 2.64 version.  Its also not
> marking the subject line [SPAM] like it did before. I'd like it to
> if possible.
>
>>>From this amount of data, can it be determined whats wrong?
>
>Any help accepted with glee & thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.