Bug 3623 - sa-learn and spamassassin don't behave right when setgid/setuid
Summary: sa-learn and spamassassin don't behave right when setgid/setuid
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: 3.0.0
Hardware: Sun Solaris
: P2 critical
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords: triage
Depends on:
Blocks:
 
Reported: 2004-07-20 13:07 UTC by Tim Bishop
Modified: 2005-06-14 15:01 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Bishop 2004-07-20 13:07:19 UTC
I need to run sa-learn setgid so it can pick up a configuration file (contain
SQL passwords, so isn't normally readable). Problem is, sa-learn doesn't work
too well when setgid (or setuid):

% sa-learn
SpamAssassin version 3.0.0-pre2-r22977
Can't open /dev/fd/4 for reading: Bad file number
 at /dev/fd/4 line 477
%

This is line 477:

pod2usage( -verbose => $verbose, -message => $message, -exitval => 64 );

Commenting it out seems to make the problem go away. No ideas on a proper
solution though.

Tim.
Comment 1 Tim Bishop 2004-10-02 14:59:37 UTC
More details on this. It might only be an issue on Solaris. Also confirmed the
problem is the same with spamassassin.

The problem seems to occur when pod2usage() is called.

I've made this test case which does the trick:

root # cat > test
#!/usr/local/bin/perl -w
use Pod::Usage;
pod2usage();
^D
root # chgrp spamassassin test
root # chmod 2755 test
root # ./test
Can't open /dev/fd/3 for reading: Bad file number
 at /dev/fd/3 line 3
root # ls -la test
-rwxr-sr-x   1 root     spamassassin      54 Oct  2 22:55 test
root # 

I've tried to google for this, but I've not found anything useful.

I think this bug, if it is a bug, should be addressed asap.
Tim.
Comment 2 Malte S. Stretz 2004-10-02 15:08:00 UTC
There were some buggy versions of Pod::Usage, so maybe you're bitten by one of 
them.  Which version do you heave?  Try 
  perl -MPod::Usage -le 'print $Pod::Usage::VERSION' 
Comment 3 Tim Bishop 2004-10-02 15:12:35 UTC
Subject: Re:  sa-learn and spamassassin don't behave right when
	setgid/setuid

> ------- Additional Comments From spamassassin-contrib@msquadrat.de  2004-10-02 15:08 -------
> There were some buggy versions of Pod::Usage, so maybe you're bitten by one of 
> them.  Which version do you heave?  Try 
>   perl -MPod::Usage -le 'print $Pod::Usage::VERSION' 

This is a fairly new installation of perl 5.8.5 with modules installed
from CPAN. Here's the version:

# perl -MPod::Usage -le 'print $Pod::Usage::VERSION'
1.16

Cheers,
Tim.

Comment 4 Sidney Markowitz 2004-10-02 15:26:20 UTC
Is this relevant?

http://london.pm.org/pipermail/london.pm/Week-of-Mon-20040906/028893.html
Comment 5 Tim Bishop 2004-10-02 15:28:39 UTC
Subject: Re:  sa-learn and spamassassin don't behave right when
	setgid/setuid

> ------- Additional Comments From sidney@sidney.com  2004-10-02 15:26 -------
> Is this relevant?
> 
> http://london.pm.org/pipermail/london.pm/Week-of-Mon-20040906/028893.html

Yup - the second part certainly sounds like the same problem.

Tim.

Comment 6 Sidney Markowitz 2004-10-02 16:32:40 UTC
Other possibly relevant things.

From perlsec http://www.perldoc.com/perl5.8.0/pod/perlsec.html

n recent years, vendors have begun to supply systems free of this inherent
security bug. On such systems, when the kernel passes the name of the set-id
script to open to the interpreter, rather than using a pathname subject to
meddling, it instead passes /dev/fd/3. This is a special file already opened on
the script, so that there can be no race condition for evil scripts to exploit.
On these systems, Perl should be compiled with -DSETUID_SCRIPTS_ARE_SECURE_NOW.
The Configure program that builds Perl tries to figure this out for itself, so
you should never have to specify this yourself. Most modern releases of SysVr4
and BSD 4.4 use this approach to avoid the kernel race condition.

From http://www.perldoc.com/perl5.8.0/lib/Pod/Usage.html

CAVEATS

By default, pod2usage() will use $0 as the path to the pod input file.
Unfortunately, not all systems on which Perl runs will set $0 properly (although
if $0 isn't found, pod2usage() will search $ENV{PATH} or else the list specified
by the -pathlist option). If this is the case for your system, you may need to
explicitly specify the path to the pod docs for the invoking script using
something similar to the following:

    pod2usage(-exitval => 2, -input => "/path/to/your/pod/docs");
Comment 7 Tim Bishop 2004-10-03 09:57:06 UTC
Subject: Re:  sa-learn and spamassassin don't behave right when
	setgid/setuid

> ------- Additional Comments From sidney@sidney.com  2004-10-02 16:32 -------
> From http://www.perldoc.com/perl5.8.0/lib/Pod/Usage.html
> 
> CAVEATS
> 
> By default, pod2usage() will use $0 as the path to the pod input file.
> Unfortunately, not all systems on which Perl runs will set $0 properly (although
> if $0 isn't found, pod2usage() will search $ENV{PATH} or else the list specified
> by the -pathlist option). If this is the case for your system, you may need to
> explicitly specify the path to the pod docs for the invoking script using
> something similar to the following:
> 
>     pod2usage(-exitval => 2, -input => "/path/to/your/pod/docs");

Well, I can confirm that adding -input to point at the program (sa-learn
or spamassassin) works. This at least gives me a temporary local fix.

I'm not sure if this is an easy one to fix in general - can the
build/install stuff for spamassassin fill this in during the
installation process?

Tim.

Comment 8 Justin Mason 2005-06-14 23:01:32 UTC
i'm going to close this WONTFIX -- (a) it's a Pod::Usage bug, (b) it only
affects --help.