SA Bugzilla – Bug 3623
sa-learn and spamassassin don't behave right when setgid/setuid
Last modified: 2005-06-14 15:01:32 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.
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.
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'
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.
Is this relevant? http://london.pm.org/pipermail/london.pm/Week-of-Mon-20040906/028893.html
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.
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");
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.
i'm going to close this WONTFIX -- (a) it's a Pod::Usage bug, (b) it only affects --help.