http://bugzilla.spamassassin.org/show_bug.cgi?id=3586
------- Additional Comments From [EMAIL PROTECTED] 2004-07-13 09:39 ------- yeah, separating the commands doesn't matter. it's a red herring anyway, we already change stuff separately. the boiled down issue here is: $<=1000; die if ($< != 1000); This fails on the default FreeBSD and Mac OS X perl installs (I'd guess probably also NetBSD and OpenBSD). We're trying to drop privilege, but setuid() away from uid 0 fails. On FreeBSD 4.9, anyway, doing some truss checking shows the perl binary not even trying the setuid() call, so the problem seems to be completely perl binary related. My guess is that either the default BSD-supplied build config, or the perl configure script, for some reason disables all setuid functionality (though they leave seteuid() functionality)). I see two issue paths we need to work on here: 1) Instead of spamd doing die, it really ought to just throw a loud warning, and return "fail". This is, after all, just a rule. 2) Figure out a way to get around this issue. It seems to be a perl binary issue, and setuid (via $<, POSIX, etc,) doesn't work at all. So IMO: - add in documentation about the issue - suggest people compile/get a different perl that does allow setuid - somehow autodetect the situation and disable "helper" rules automatically. users will probably be confused that DCC/etc doesn't work, we'll have to say RTFM a lot... I'm not really sure how to autodetect this though. It's not an OS issue, since you can get different perl binaries that work fine on FreeBSD, for instance. So we can't just disable if $^O is set appropriately. It doesn't seem to be obviously available via %Config, based on the results thus far. FWIW: This issue just affects DCC, and Pyzor: setuid_to_euid() is only called by helper_app_pipe_open_unix(), which is only called by helper_app_pipe_open(), which is only called via Dns.pm and Reporter.pm for DCC and Pyzor. Just so we're clear this doesn't impact the majority of SA functionality. :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
