I've seen this problem as well, even in the latest "ports" version. Still
runs as root. If I apply the attached patch (obtained from one of the
bugzilla entries), it works properly. Running FBSD 4.11 w/perl 5.6.2
(5.8.7 had the same problem, I backed out of 5.8 since it chewed up more
memory than I was comfortable with).
Charles
On Mon, 8 Aug 2005, Dan Mahoney, System Admin wrote:
On Tue, 26 Apr 2005, Justin Mason wrote:
It's specifically a problem with perl on *BSD platforms -- there's
a bug open about it, but it's stalled because we don't have any
developers with BSD machines ;)
Anyone want a test machine where this is occurring? Where it DIDN'T occur
before under 3.0.3? Contact me offlist.
I've had a bugzilla report sitting in "NEW" status for over a month now, I
think. I flagged it as "security" because I a) thought maybe there was some
priority to that and b) actually believe it to be, but nobody has done
anything with it.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4498
-Dan
at least on some platforms (MacOS X) it appears perl's setuid
support substantially does not work.
--j.
Brandon Kuczenski writes:
I've seen this question posted a couple times in the mailing list archives
(from October 2004) but no resolution. The question again:
I'm running SpamAssassin 3.0.2 on FreeBSD 4.10 in spamc/spamd format with
the '-u spamd' flag. Problem is, all the child processes are running as
root:
$ ps aux | grep spam
root 333 0.0 10.1 27636 25932 ?? I 11Apr05 1:03.83 spamd
child (perl)
root 332 0.0 10.5 29020 27032 ?? I 11Apr05 1:07.96 spamd
child (perl)
root 331 0.0 9.7 26544 24852 ?? I 11Apr05 0:52.68 spamd
child (perl)
root 330 0.0 9.9 27152 25524 ?? I 11Apr05 1:04.40 spamd
child (perl)
root 329 0.0 9.8 26864 25116 ?? I 11Apr05 0:58.08 spamd
child (perl)
spamd 294 0.0 7.1 22392 18220 ?? Is 11Apr05 0:01.61
/usr/local/bin/spamd -d -c -u spamd -H /home/spamd -r /var/run/spamd.pid
(perl)
$
Is this intended or is it a bug? The two threads I've seen that pertain
to it (both dating from Oct04) are left unresolved:
http://thread.gmane.org/gmane.mail.spam.spamassassin.general/57900
http://thread.gmane.org/gmane.mail.spam.spamassassin.general/58087
The practical consequence of this (aside from the unorthodoxy -- undesired
processes owned by root) is that the permissions of my
~user/.spamassassin/bayes_journal file get changed to root:spamd 0660.
I wanted them to be spamd:user 0660, so that the user can run
sa-learn without asking for root's help. Is that not the 'right way' to
do things?
Has there been a resolution to this question? If not, .. doesn't
everybody have this problem? Or is it not a problem? If not, why not?
-Brandon
------------ Output from gpg ------------
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Tue Apr 26 19:09:08 2005 EDT using DSA key ID 298BC7D0
gpg: Good signature from "Justin Mason <[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0
--
"Don't try to out-wierd me. I get stranger things than you free with my
breakfast cereal."
-Button seen at I-CON XVII (and subsequently purchased)
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
--- spamd.old Wed Oct 13 16:49:58 2004
+++ spamd Thu Oct 14 20:15:53 2004
@@ -700,6 +700,15 @@
# Change UID
$> = $uuid; # effective uid
$< = $uuid; # real uid. we now cannot setuid anymore
+
+ if ( $< != $uuid ) {
+ warn("initial attempt to change real uid failed, trying BSD workaround")
if $opt{'debug'};
+
+ $> = $<; # revert euid to ruid
+ $< = $uuid; # change ruid to target
+ $> = $uuid; # change euid back to target
+ }
+
if ( $> != $uuid and $> != ( $uuid - 2**32 ) ) {
die "fatal: setuid to uid $uuid failed\n";
}
