severity 407223 normal
tags 407223 + pending
thanks
Steve Langasek wrote on 17/01/2007 05:39:
> severity 407223 important
> tags 407223 unreproducible
> thanks
>
> On Tue, Jan 16, 2007 at 05:12:07PM -0700, Daniel Webb wrote:
>
>>Setting up spampd (2.30-15) ...
>>Starting spam checking proxy daemon: spampdInsecure $ENV{BASH_ENV} while
>>running with -T switch at /usr/sbin/spampd line 814.
>>invoke-rc.d: initscript spampd, action "start" failed.
>>dpkg: error processing spampd (--configure):
>> subprocess post-installation script returned error exit status 9
>>Errors were encountered while processing:
>> spampd
>>E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Not that this code isn't horrible to behold, but I'm not able to reproduce
> this error at all on a fresh install, including by setting BASH_ENV
> explicitly in my environment.
First of all: Thanks Steve for looking into this. I would be grateful
for a cleaner solution to the problem. I'm thinking about simply moving
on and not support sarge backports anymore, which would eliminate the
code in question completely. After all, it is only a workaround (and
admittedly an ugly one) for a regression in the Perl syslog
implementation (a security upgrade to libnet-server-perl removed a -
though undocumented - feature).
Anyway, though Daniel probably identified the original cause to be an
out of memory situation (quite likely since spamassassin and thus spampd
use a lot of memory), I still see that my workaround should remove
BASH_ENV from the environment before executing a shell. So I implemented
a fix in my SVN repository which I will probably upload later.
Downgrading severity to normal though since it doesn't seem to be a real
problem in my code but merely an oversight which I don't see any attack
vector for as spampd isn't SUID.
Anyway: Steve, I would consider removing that workaround in an upload to
etch via proposed-updates (or via sid if I get a notice from you early
enough), since etch actually doesn't need that workaround anyway. Is
there a chance of it getting approved? The update would remove these
lines from the spampd script:
# Also disable format usage on Debian systems
$ENV{PATH}="/usr/bin:/usr/sbin:/bin:/usr/sbin";
delete $ENV{BASH_ENV};
if ( ( -f "/usr/bin/dpkg" ) && ( `dpkg --compare-versions \$(
COLUMNS=255 dpkg -l libnet-server-perl |grep libnet-server-perl | awk '{
print \$3; }' ) ge 0.87-3sarge1 ; echo \$?` == 0 ) ) {
# Sarge version with backport fix
$pfs_uses_format = 0;
}
As said, etch doesn't need the workaround anyway because etch uses
libnet-server-perl version 0.94 which is handled in the test above the
Debian specific workaround already.
Regards,
Sven
signature.asc
Description: OpenPGP digital signature
