develooper Front page | perl.perl5.porters | Postings from October 2013

Re: [perl #119855] chdir, taint, and if

Thread Previous | Thread Next
Eirik Berg Hanssen
October 1, 2013 09:24
Re: [perl #119855] chdir, taint, and if
Message ID:
On Tue, Oct 1, 2013 at 9:55 AM, Dave Mitchell <> wrote:

> On Sat, Sep 28, 2013 at 04:57:31AM -0600, Ben Hildred wrote:
> > So where would this be documented? Before reporting this issue I checked
> > the relevant man pages, my dead tree copy of the camel, and google; so if
> > this is not a bug in the code as you assert, might it be something that
> > needs to be documented?
> In perlsec, it says:
>     For efficiency reasons, Perl takes a conservative view of
>     whether data is tainted.  If an expression contains tainted data,
>     any subexpression may be considered tainted, even if the value
>     of the subexpression is not itself affected by the tainted data.
> perhaps we should s/an expression/a statement/ ?

  I was thinking along the same lines, but this is referring to something
else: Whether the data (the subexpression evaluates to) is tainted or not,
not whether the command that attempts "to do something insecure" involves
tainted data.

  What lacks documentation is how this involvement is determined.  And ...
it's not simple ... hang on ...

my $x = $taintedvar==16 ? '.' : '..'; # $x is not tainted, thanks to an
explicit exception
chdir($x); # involves no tainted data: success!

chdir(my $y = $taintedvar==16 ? '.' : '..'); # involves no tainted data:

chdir((my $z = $taintedvar==16) ? '.' : '..'); # involves no tainted data:

chdir($taintedvar==16 ? '.' : '..'); # somehow involves tainted data
(though none is passed to chdir): fails!

chdir( sub { return '.' if pop==16; '..' }->($taintedvar) ); # somehow does
not involve tainted data: success!

  (If you replace those chdir calls with calls to &mychdir (simply wrapping
chdir), they all succeed.)

  Is this intentional?  I doubt it.  Is it buggy?  Not necessarily.  It may
be intentionally avoiding the detailed tracking of taintedness within a

  If so, perhaps an addition to the documentation could go like so:

  «Likewise for efficiency reasons, Perl may avoid tracking taintedness
within a non-compound statement.  If a non-compound statement uses tainted
data, any subexpression may be considered to be using tainted data, even if
the operands seen by the subexpression are not themselves tainted.»

  Or hey, p5p could decide that these are in fact bugs.  They're certainly
bizarre enough.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About