Same problem on FreeBSD. BSD setuid/seteuid differs from Linux implementation.
spamd must be patched to perform setuid calls in different order.
idea(p1)root:/home/arkadi/build> cat test-setuid.pl
#!/usr/bin/perl
$( = 2030;
$) = "2030 2030";
$< = 2030;
$> = 2030;
print `/usr/bin/id`;
idea(p1)root:/home/arkadi/build> ./test-setuid.pl
uid=2030(pkadmin) gid=2030(pkadmin) groups=2030(pkadmin)
idea(p1)root:/home/arkadi/build> cat test-setuid-bad.pl
#!/usr/bin/perl
$) = "2030 2030";
$( = 2030;
$> = 2030;
$< = 2030;
print `/usr/bin/id`;
idea(p1)root:/home/arkadi/build> ./test-setuid-bad.pl
uid=0(root) euid=2030(pkadmin) gid=2030(pkadmin) groups=2030(pkadmin)
idea(p1)root:/home/arkadi/build> uname -r
4.9-RELEASE-p3

Both test cases works fine on Linux, so there should be no problem.

Brad, please change the Component/Hardware/OS bug attributes.

Created attachment 2640 [details]
Fix setuid prob for *BSD

Updated for all freebsd. 

attached patch (2005.02.06 09:03) does not fix problem on Mac OS X. Same
symptoms (initially spamd child has correct uid; after processing one message,
spamd child runs as root). 

Actually, there's a different issue here; if I recall correctly, spamd's
children run as ruid=root euid=root when they're *not* processing a message, so
that they can switch to other users' UIDs during a scan.

This is required because a single child proc may scan several hundred
messages before exiting; it's a preforked server pool, not a single-scan
child as in previous versions of SpamAssassin.     

btw, regarding the patch, how does that relate to bug 3586, which was a rewrite
of the setuid code in spamd to work with MacOS X and explicitly changed that
code to what it is now?

need to figure out what's going on here for 3.1.0

Subject: Re:  When run as nobody, child processess get root privileges

On Mon, Feb 07, 2005 at 11:11:00AM -0800, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Actually, there's a different issue here; if I recall correctly, spamd's
> children run as ruid=root euid=root when they're *not* processing a message, so
> that they can switch to other users' UIDs during a scan.

IIRC, in 3.0, if -u is given on the commandline, that should be the user
used for parent and children.

In 3.1, the parent will always be root, and the children will be the -u
user.  (this is to standardize our behavior with the rest of the world,
and allow things like HUP to actually work...)

'In 3.1, the parent will always be root, and the children will be the -u
user.  (this is to standardize our behavior with the rest of the world,
and allow things like HUP to actually work...)'

sure -- but the bug here is that the children are running as root, not as nobody
(the -u user).

I used the following test to check spamd 3.0.2 (unpatched) on my Mac OS X 10.3.7
Server box:

while [ /bin/true ] ; do
    ps xuwwa|grep spam | grep child | grep -v "^root"
done

Initially, it spat out (repeatedly :-) every spamd child process, with "nobody"
as the owner. As mail came in, it was assigned to a spamd child process, which
ran the checks. Somewhere at/near the end of processing the message was when the
spamd child process stopped running as nobody and started running as root (I
could tell by watching the spamd child process CPU time increasing). Eventually
my little test app output nothing, indicating that all spamd children were
running as root. 

As new mail was processed by spamd children that have already processed one
message, those spamd children are scanning my mail while running as root. So
spamd children runs as nobody the first time they process a message, but never
again. 

*** This bug has been marked as a duplicate of 3897 ***

The solution for bug 3897 does in fact resolve this bug on Mac OS X Server.
Thanks everybody!