ports/78700: sa-spamd script does not play well with spamd "-u" flag

[Jeremy Chadwick]

>Number:         78700
>Category:       ports
>Synopsis:       sa-spamd script does not play well with spamd "-u" flag
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 11 14:30:03 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Jeremy Chadwick
>Release:        FreeBSD 4.11-STABLE i386
>Organization:
Parodius Networking
>Environment:
System: FreeBSD pentarou.parodius.com 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Feb 5 08:39:49 PST 2005 root at pentarou.parodius.com:/usr/obj/usr/src/sys/PENTAROU i386
>Description:
The sa-spamd.sh rc(8) script is not friendly with situations where
spamd needs to run as a non-root user.  If you start spamd in such environments,
you'll receive a warning that spamd is switching credentials to a non-root user
(default nobody).  Example:

Mar 11 06:15:01 medusa spamd[56571]: connection from localhost [127.0.0.1] at port 55031
Mar 11 06:15:01 medusa spamd[56571]: info: setuid to root succeeded
Mar 11 06:15:01 medusa spamd[56571]: Still running as root: user not specified with -u, not found, or set to root.  Fall back to nobody.
Mar 11 06:15:01 medusa spamd[56571]: processing message <200503111415.j2BEF1Ah056662 at medusa.parodius.com> for root:65534.

As the warning in the log is generated __once per Email__, heavily loaded
machines generate excessive syslog traffic.

This can be avoided by setting spamd_flags to contain "-u nobody".  This
works great, except that it induces a new problem relating to the
ownership of the PID file:

Mar 11 06:00:30 medusa spamd[55988]: Can't write to PID file: Permission denied

If things were simple, an admin could just do the following:

	touch /var/run/spamd.pid
	chown nobody:nobody /var/run/spamd.pid

...except that the sa-spamd.sh rc(8) script deliberately removes the pidfile
when shutting down spamd.

I have no idea how spamd handles signals, so one should test that to see
how the pidfile is maintained in such situations (i.e. SIGTERM, SIGUSR1, etc.).

>How-To-Repeat:
1.  Shut down spamd
2.  Set spamd_flags in rc.conf to contain "-u nobody"
3.  Start spamd
4.  Send someone mail to an account which gets processed by spamd
5.  Look at /var/log/maillog; you will find a message along these lines:

>Fix:
There's a couple solutions available.  Pick and choose whichever:

1.  Don't remove the pidfile, period.  I can't recommend this since I
know of situations where spamd will not remove the pidfile when dying,
etc. etc...  So I believe the rm -f on the pidfile to be a good thing.

2.  Grep through the spamd_flags rc.conf variable to see if -u is
specified; if it is, touch and chown spamd_pidfile before the
actual spamd process starts.  This is excessive, in lieu of option 3...

3.  Create a new "spamd_user" rc flag, and add appropriate framework
for supporting this inside of sa-spamd.sh.  This would be the best
solution.

>Release-Note:
>Audit-Trail:
>Unformatted: