in reply to Re: Re: Re: Taint bug with backticks in variable assignments
in thread Taint bug with backticks in variable assignments

Maybe it's the way I'm reading that, but take the example below, I don't see how that applies. The second element isn't referencing anything that could be tainted.
#!/usr/bin/perl -T $ENV{PATH} = '/usr/bin:/usr/local/bin:/bin'; $ENV{ENV} = ''; my $commands = [ `mktemp /tmp/temp.XXXXXX`, `mktemp /tmp/temp.XXXXXX`, ];


-Lee

"To be civilized is to deny one's nature."

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Taint bug with backticks in variable assignments
by Anonymous Monk on Nov 19, 2003 at 16:26 UTC
    Doesn't matter. "It would be inefficient for every operator to test every argument for taintedness." Once you use tainted data in an expression, any unsafe operator in the same expression is going to trigger a taint exception now matter what its arguments are.
      One more thing, why is this ok then?
      #!/usr/bin/perl -T use strict; use warnings; $ENV{PATH} = '/usr/bin:/usr/local/bin:/bin'; $ENV{ENV} = ''; my $tainted = `echo "FOO"`; my $vars = [ $tainted, `echo "BAR"`, ];
      -Lee

      "To be civilized is to deny one's nature."
        Interesting...
        rc <1> srefgen sK/1 ->rd - <1> ex-list lKRM ->rc rb <@> anonlist sKRM/1 ->rc r7 <0> pushmark s ->r8 r8 <0> padsv[$tainted:50,end] l ->r9 ra <1> backtick[t6] lK ->rb - <0> ex-pushmark s ->r9 r9 <$> const(PV "echo \"BAR\"") s ->ra
        The taintedness only gets checked or tirggered by an operation; 'padsv' just pushes a value on the stack, so the expression as a whole isn't tainted yet.
      Thanks, I see what you're getting at. Though I wouldn't think a ref constructor would trigger it. I could see the whole assignment being tainted, but it seems in this example counterintuitive.


      -Lee

      "To be civilized is to deny one's nature."