Re: spamassassin running as 'nobody' causes problems

fixed top-posting...

On Tue, Jan 30, 2007 at 08:40:59AM -0800, Brian Hostetler wrote:



On Mon, Jan 29, 2007 at 05:06:18PM -0800, Andrew
Sackville-West wrote:
/var/log/mail.log

Jan 29 10:32:36 bigmomma spamd[32442]: spamd: connection from bigmomma
[127.0.0.1] at port 41420
Jan 29 10:32:36 bigmomma spamd[32442]: spamd: setuid to nobody
succeeded
Jan 29 10:32:36 bigmomma spamd[32442]: spamd: creating default_prefs:
/nonexistent/.spamassassin/user_prefs
Jan 29 10:32:36 bigmomma spamd[32442]: mkdir /nonexistent: Permission
denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530

Jan 29 10:32:36 bigmomma spamd[32442]: config: cannot write to
/nonexistent/.spamassassin/user_prefs: No such file or directory
Jan 29 10:32:36 bigmomma spamd[32442]: spamd: failed to create
readable default_prefs: /nonexistent/.spamassassin/user_prefs
Jan 29 10:32:36 bigmomma spamd[32442]: mkdir /nonexistent: Permission
denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530
Jan 29 10:32:36 bigmomma spamd[32442]: spamd: checking message
<20070129190811.6a637656@.bredbandsbolaget.se> for nobody:65534
Jan 29 10:32:49 bigmomma spamd[32442]: mkdir /nonexistent: Permission
denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530
Jan 29 10:32:49 bigmomma spamd[32442]: locker: safe_lock: cannot
create tmp lockfile
/nonexistent/.spamassassin/auto-whitelist.lock.bigmomma.
32442 for /nonexistent/.spamassassin/auto-whitelist.lock: No such file
or
directory
Jan 29 10:32:49 bigmomma spamd[32442]: auto-whitelist: open of
auto-whitelist file failed: locker: safe_lock: cannot create tmp
lockfile /non
existent/.spamassassin/auto-whitelist.lock.bigmomma.32442 for
/nonexistent/.spamassassin/auto-whitelist.lock: No such file or
directory
Jan 29 10:32:49 bigmomma spamd[32442]: spamd: clean message (0.5/5.0)
for nobody:65534 in 12.8 seconds, 6620 bytes.
Jan 29 10:32:49 bigmomma spamd[32442]: spamd: result: . 0 -
PLING_PLING
scantime=12.8,size=6620,user=nobody,uid=65534,required_score=5.0,rhos
t=bigmomma,raddr=127.0.0.1,rport=41420,mid=<20070129190811.6a637656@.bredbandsbolaget.se>,autolearn=no


As I understand it, and frmo a little google, spamd changes its uid to
'nobody' when it get a message to scan. This causes a problem as it
tries to update the AWL and bayes database files in
its $HOME with is
nonexistent. One recommendation I found was to change the user for
spamd from nobody to spamd, and create that user for just this
purpose. This seems fine, but I don't like to migrate too far from
default configs. Any other suggestions? is there something simple I'm
missing here? (probably). is this new user, spamd, the way to go or
should I be tweaking some other conf to make this work.

okay solved to my satisfaction:

modified /etc/default/spamassassin thus:

OPTIONS="--create-prefs --max-children 5 --helper-home-dir -D
-x --virtual-config-dir=/srv/Mail/spamassassin"

-x turns off the per-user configs, so its stops trying to create
/nonexistent...

--virtual-config-dir=... does just that, point spamd to the specified
directory for its AWL files and bayes_* files.

seems to work for me, though that -D sure puts up lots of nice
output
:)

thanks all

A


I've moved from Solaris to Debian and have a new
sendmail/spamassassin/milter installation (non-compiled) and I'm
getting these permissions errors as well. I keep a .spamassassin in my
home directory with a whitelist, userprefs, and bayes files. If I move
these to a central location, it's a requirement that user nobody has
read and write access or just read?

Essentially what happens is the default install of SA in Deb runs
the child processes as 'nobody' when SA is called by root. This is
what happens when SA is used in the ACL's of exim and probably in
sendmail as well. sendmail calles SA as root, SA says "no can't be
root" and forks a child with uid 'nobody'. SA also uses the
"--create-prefs" option (see above OPTION line) which tells spamd to
create the user's preference files in $HOME/.spamassassin/ but there
is no $HOME for 'nobody'.

Many people call SA from their local .procmailrc in which case SA is
called as that user and spamd forks a child with that users uid and
the prefs are created in $HOME/.spamassassin and all is well in that
scenario.

So you have a couple of options.

1) move your SA calls to some local-user-initiated setup such a
procmail or whatever. In this case, as I said above, it calls SA as
that user and all is fine. This however places the interfacing with SA
in the hands of the user -- not ideal for *my* situation.

2) change the way spamd runs to use its own user (adduser spamd, for
example). you do this with the -u flag in
/etc/default/spamassassin. In this case spamd will always run as that
user and the preferences will get stored in
/home/spamd/.spamassassin... also not, for my case a great solution as
its another user account to be maintained in some way. It does however
provide site-wide SA control and centralized bayesian filters etc.

3) do what I did -- change the way spamd runs to tell it *NOT* to look
for $HOME/.spamassassin (this is the -x flag above) and then tell it where
to look for the prefs (this is the --virtual-config-dir above). This
is the solution I settled on. It means I get site-wide spam control,
no extra user/group to maintain, and centralised storage of the AWL,
bayes_* etc.

BTW, using 3 above, I left the '--create-prefs' in place and it did
indeed create its prefs in /srv/Mail/spamassassin as confirmed here:

andrew@bigmomma:~$ ls -l /srv/Mail/spamassassin/
total 576
-rw------- 1 root root 24576 2007-01-30 10:24 auto-whitelist
-rw------- 1 nobody nogroup 24576 2007-01-30 10:24 bayes_seen
-rw------- 1 nobody nogroup 651264 2007-01-30 10:24 bayes_toks

note the uid/gid of the the bayes_* files. and apparently, the
auto-whitelist is handled by the parent spamd which is running as
root. interesting that. oh, I also setup the bayes_path in
/etc/spamassassin/local.cf as

# location for bayes filter database files
# setup 1/2907 ASW, per spamassassin wiki
bayes_path /srv/Mail/spamassassin/bayes


There are surely multiple ways to do this. That's just what I figured
out. and I'm a total SA newb, so take it with a grain of salt.

A

Attachment: signature.asc
Description: Digital signature

Relevant Pages

  • Re: spamassassin running as nobody causes problems
    ... spamassassin running as 'nobody' causes problems ... I've recently abandoned my increasingly unwieldy bogofilter ... As I understand it, and frmo a little google, spamd changes its uid to ...
    (Debian-User)
  • Re: spamassassin running as nobody causes problems
    ... 'nobody' when it get a message to scan. ... spamd from nobody to spamd, and create that user for just this ... spamassassin runs out of procmail during local delivery. ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    (Debian-User)
  • Re: How do I teach Spam Assassin?
    ... But as spamd is running before each user's mail ... I've started using sa-learn regularly. ... spamd (as root), so I have made sure I run all my sa-learn invocations ... and the bayes files are being updated in ...
    (Fedora)
  • Re: How do I teach Spam Assassin?
    ... > Since reading this thread, ... > run spamd (as root), so I have made sure I run all my sa-learn ... and the bayes files are being updated in ... > It's not clear to me from the spamd manpage if spamd it will use ...
    (Fedora)
  • Re: spamassassin a possible security risk?
    ... > Looks like you are ignoring two important security recommendations: ... never work as root ... Spamd, itself, is not what's at issue in that message...it's actually ... client connecting to spamd as 'root'. ...
    (Fedora)