spamassassin running as 'nobody' causes problems

On Mon, Jan 29, 2007 at 08:31:31PM -0500, Greg Folkert wrote:
> On Mon, 2007-01-29 at 17:24 -0800, Andrew Sackville-West wrote:
> > On Mon, Jan 29, 2007 at 05:18:17PM -0800, Raquel wrote:
> > > On Mon, 29 Jan 2007 17:06:18 -0800
> > > Andrew Sackville-West wrote:
> > >
> > > > howdy folks.
> > > >
> > >
> > > >
> > > > 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.
> > > >
> > > > thanks
> > > >
> > > > A
> > > >
> > >
> > > I run Sendmail and procmail, along with SpamAssassin. In
> > > /etc/procmailrc I use:
> > >
> > > # Send through SpamAssassin
> > > DROPPRIVS=yes
> > > :0fw
> > > * < 256000
> > > | /usr/bin/spamc
> >
> > yeah, I've seen this solution too, but I'm running SA through exim's
> > ACL's and not through procmail. I leave it to my users to determine
> > what they do with their spam, I just mark it up before delivery.
>
> I am running SA using SA-Exim at SMTP time. This then rejects the mail
> before it is accepted, if it doesn't do RFC822 properly.
>
> Yeah, I know this is against the RFC, but it has reduced the processing
> on my machine by magnitudes. If they really want to send it to me,
> they'll do it the right way.

nice!

A

Greg Folkert wrote:

> I am running SA using SA-Exim at SMTP time. This then rejects the mail
> before it is accepted, if it doesn't do RFC822 properly.
>
> Yeah, I know this is against the RFC, but it has reduced the processing
> on my machine by magnitudes. If they really want to send it to me,
> they'll do it the right way.

Do you have spamassassin configured so each user has their own
~/.spamassassin read in for email destined for them? I've been trying
to figure out how to do that so I can implement it at my site and
suggest it to people considering far worse alternatives
(challenge-response, address munging, etc).

--

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

Greg Folkert wrote:> I am running SA using SA-Exim at SMTP time. This then rejects the mail> before it is accepted, if it doesn't do RFC822 properly.> > Yeah, I know this is against the RFC, but it has reduced the processing> on my machine by magnitudes. If they really want to send it to me,> they'll do it the right way.Do you have spamassassin configured so each user has their own~/.spamassassin read in for email destined for them?  I've been tryingto figure out how to do that so I can implement it at my site andsuggest it to people considering far worse alternatives(challenge-response,
address munging, etc).Greg, I used to have it set up this way on my Solaris system, where I compiled and configured all the components (sendmail/spamassassin/milter) by hand over the course of a "long time", but never had a permission or lock error. Moving to Debian and using the packages...the installation was a snap, but it appears to force you into a certain direction by default that contradicts my previous method of per user configuration. If you can figure out how to get it to work that way, please tell us all, but I'm probably going with one of Andrew's suggestions and create a central repository for spamassassin config for user spamd...B

Any questions? Get answers on any topic at Yahoo! Answers. Try it now.