in reply to Why a taint flag on test files?

From a users perspective, it is a good thing to know that the test script is not going to do anything odd with your personel system/data.

It is most likely that the taint checking was turned on because a lot of people will ague that it is always a good idea unless you have a specific reason not too. From the philosophy "Make your error on the side of caution" school of thought.

"Never take yourself too seriously, because everyone knows that fat birds dont fly" -FLC

Replies are listed 'Best First'.
Re^2: Why a taint flag on test files?
by xdg (Monsignor) on Oct 13, 2005 at 19:48 UTC
    From a users perspective, it is a good thing to know that the test script is not going to do anything odd with your personel system/data.

    That's not what taint mode does, though -- it flags external data, not internal data. A test script could very well do this evil thing:

    WARNING -- Don't try this at home.

    #!/usr/bin/perl -T

#### DO NOT ACTUALLY RUN THIS CODE ####

use Test::More tests => 1;
use File::Path;
use File::Spec;

my $n = rmtree( File::Spec->rootdir(), 0, 1);

ok( $n, "Deleted at least one file from the root directory" );

    [download]

    Sadly, Perl doesn't have a nice sandbox like Java. Good reason not build/test modules as root, eh?

    What the taint flag will do is limit the directories in @INC. From perlsec:

    When the taint mode ("-T") is in effect, the "." directory is removed from @INC, and the environment variables "PERL5LIB" and "PERLLIB" are ignored by Perl. You can still adjust @INC from outside the program by using the "-I" command line option as explained in perlrun. The two environment variables are ignored because they are obscured, and a user running a program could be unaware that they are set, whereas the "-I" option is clearly visible and therefore permitted.

    For testing, I'm still not sure if that is or isn't desireable. What if a user has their own private installation in PERL5LIB?

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
[select]
      For testing, I'm still not sure if that is or isn't desireable. What if a user has their own private installation in PERL5LIB?
      Then make test fails because the current setup will not work under taint. Which is better then letting CPAN install it, and then find out your program isn't going to work under taint.

      The user has some options though. He can abandon the attempts to install it. He can install whatever is in his private installation in the standard directories. He can recompile perl to have his PERL5LIB part of the default @INC - perhaps by creating a private perl installation. He can make sure the directories of his PERL5LIB are put as -I arguments when the test scripts are called. He can modify the test scripts to include the relevant directories in @INC. He can modify the test scripts and remove the -T or -t options.

      It's a delicate issue. Should you, or shouldn't you run tests with taint enabled? Not because the environment is untrusted, but because the purpose of tests is to show the module works correctly. And that would include running correctly with taint enabled.

      Perl --((8:>*
[reply]

In Section Seekers of Perl Wisdom