On Fri, Apr 05, 2013 at 06:15:29PM -0700, David Benfell wrote: > > Casting about on the web, I gather this is an ownership/permissions > issue. That'd be fine and I might know what to do about it if I knew > where spamd was trying to create it and, for that matter, under what user. > I finally caught in the logs where spamassassin setuid to nobody and found in the man page that there is a -u to change this. So I created a spamd user, created the home directory, and a .spamassassin folder inside that directory. And of course changed ownership on the whole shbang. It does not appear to be honoring this. I'm still seeing messages like: Apr 06 00:21:12 munich.parts-unknown.org spamd[29794]: spamd: creating default_prefs: //.spamassassin/user_prefs Apr 06 00:21:12 munich.parts-unknown.org spamd[29794]: config: cannot create user preferences file //.spamassassin/user_prefs: No such file or directory Apr 06 00:21:12 munich.parts-unknown.org spamd[29794]: spamd: failed to create readable default_prefs: //.spamassassin/user_prefs and Apr 06 00:21:18 munich.parts-unknown.org spamd[29794]: plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /.spamassassin/bayes.lock.munich.parts-unknown.org.29794 for /.spamassassin/bayes.lock Apr 06 00:21:18 munich.parts-unknown.org spamd[29794]: spamd: identified spam (26.4/5.0) for nobody:997 in 5.5 seconds, 885 bytes. It still appears to running as nobody, judging from the last message. And it is, as I now understand, attempting to create these files in the root directory. But if spamd is indeed not honoring the -u option, I'm guessing this problem is upstream.
Attachment:
pgpdYKm2WfFoo.pgp
Description: PGP signature
