spamass-milt-list
[Top][All Lists]
Advanced

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

Re: Debian spamass-milt help needed


From: Dan Nelson
Subject: Re: Debian spamass-milt help needed
Date: Wed, 21 May 2003 10:45:09 -0500
User-agent: Mutt/1.5.4i

In the last episode (May 21), Derek J. Balling said:
> Now, I'm seeing:
> 
> May 21 11:25:04 narn spamd[12812]: logmsg: Creating default_prefs 
> [/home/dredd/.spamassassin/user_prefs]
> May 21 11:25:04 narn spamd[12812]: Creating default_prefs 
> [/home/dredd/.spamassassin/user_prefs]
> May 21 11:25:04 narn spamd[12812]: debug: using "/nonexistent/.spamassassin" 
> for user state dir
> May 21 11:25:04 narn spamd[12812]: debug: mkdir /nonexistent/.spamassassin 
> failed: mkdir /nonexistent: Permission  denied at 
> /usr/share/perl5/Mail/SpamAssassin.pm line 1181
> May 21 11:25:04 narn spamd[12812]: Cannot write to 
> /home/dredd/.spamassassin/user_prefs: No such file or directory
> May 21 11:25:04 narn spamd[12812]: logmsg: Couldn't create readable 
> default_prefs for [/home/dredd/.spamassassin/user_prefs]
> May 21 11:25:04 narn spamd[12812]: Couldn't create readable default_prefs for 
> [/home/dredd/.spamassassin/user_prefs]
> May 21 11:25:04 narn spamd[12812]: debug: read_scoreonly_config: cannot open 
> "/home/dredd/.spamassassin/user_prefs": No such file or directory
> May 21 11:25:04 narn spamd[12812]: debug: user has changed
> May 21 11:25:04 narn spamd[12812]: debug: bayes: 12812 untie-ing
> May 21 11:25:04 narn spamd[12812]: debug: using "/home/dredd/.spamassassin" 
> for user state dir
> May 21 11:25:04 narn spamd[12812]: debug: mkdir /home/dredd/.spamassassin 
> failed: mkdir /home/dredd/.spamassassin:  Permission denied at 
> /usr/share/perl5/Mail/SpamAssassin.pm line 1181   No such file or directory
> May 21 11:25:04 narn spamd[12812]: debug: bayes: no dbs present, cannot scan: 
> /home/dredd/.spamassassin/bayes_toks

(lines unwrapped for readability)

Ok, now this looks reasonable.  If you run spamd with -u nobody, that
forces it to setuid() itself to the nobody user, which means its
default settings directory is whatever nobody's is (i.e.
/nonexistant), and it also means that it will not be able to modify
anything in regular users' directories if the permissions don't allow
it.  I don't think any of the log lines you pasted are fatal.

So you've got four choices:

* Remove -u nobody from spamd.  The daemon will run as root.  Children
  will setuid() themselves to the appropriate userid when processing
  mail.

* Make sure ~/.spamassassin is world-readable and has all the necessary
  config files.  If you are using bayes, you may need to make the
  database files world-writable.

* Make ~/.spamassassin world-writable, and let spamd create whatever
  files it needs.

* Create a special sa user and group, run spamd with "-u sa", set
  ~/.spamassassin's group ownership to sa, and add group read/write
  access to it.  Let spamd create whatever files it needs.

-- 
        Dan Nelson
        address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]