On Wed, Feb 12, 2003 at 10:57:29PM +1100, Bradley Baetz wrote:
> On Tue, Feb 11, 2003 at 02:38:06PM +0000, Tim Bunce wrote:
> > >
> > > > ok 102 at line 316
> > > > fetchrow_hashref('NAME_uc')
> > > > ok 103 at line 319
> > > > Insecure dependency in parameter 1 of
> > > > DBI::st=HASH(0x1c1100)->FETCH method call while running with -T
> > > > switch at t/10examp.t line 320.
>
> OK, I managed to find a box with 5.005_03 installed, and after fixing
> the bogus Makefile makemaker generated so that ti didn't try to depend
> on headers not present in 5.005, I spent some time this evening looking
> into this. This occurs with 5.005_03 and 5.6.0 (but not 5.6.1).
>
> Whats happening is that the fetch called from the fetchrow_hashref
> suceeds (line 3463 of DBI.xs). keyattrib is 'NAME_uc', and we
> successfully hv_fetch it in line 3482. Then we have the next line:
>
> ka_rv = newSVsv(ka_rv); /* copy to invoke FETCH magic */
>
> and that fails. I'm not quite sure what the magic happening is, but the
> 'parameter 1' in the error message is indeed 'NAME_uc' (I changed the
> debug line to print that). What exactly is being fetched here?
>
> [Side note: there are some bugs with at least 5.005_03, where stuff
> which is in a hash can cause the entire hash to become tainted if one
> element is. This has been noticed when using template toolkit in
> bugzilla - a var is untainted when it goes into the template, and
> tainted when it arrives in the template. (This is one reason why
> Bugzilla no longer supports perl5.005) I never succeeded in a standalone
> test case (ie without TT) and it was already fixed under 5.6.
>
> As well, 5.6.0 is picky about what defines a tainted expression:
>
> my @selectnames = map($columns{$_}, @axis_fields);
>
> will taint @selectnames if @axis_fields is tainted under 5.6.0, but not
> under 5.6.1 or later. |$foo = 1 if $taintedVar| also taints $foo
> sometimes. I don't know if something similar to that is the issue here.
> Theres that 'affects sv_setsv()'s called within same perl statement'
> comment in _get_fbav, bnut I don't know enough perl to know if thats an
> issue here.
> ]
>
> At this stage, I'm lost. I have no idea how xs tie magic works, or what
> is happening. Standalone ->fetchrow_hashref fails too, so this isn't a
> DBD::ExampleP thing with the directory stuff, which is what I thought at
> first.
>
> ->fetchrow_hashref works on at least 5.6.0 (haven't tried 5.005_03) if
> TaintIn is enabled, but TaintOut isn't, or the other way arround, which
> makes sense given what I think is happening.
>
> Suggestions for a fix, or how to track this down, or something?
>
> Bradley
Thanks for digging into this!
Here's something I wrote previously that may give some ideas:
> Something is causing the perl internal PL_tainted variable to
> get set before the fetchrow_hashref code in DBI.xs reaches the line:
> ka_rv = newSVsv(ka_rv); /* copy to invoke FETCH magic */
>
> If you're handy with a C debugger then run the t/10examp.t script
> under both the perl debugger and C debugger. Stop before that
> test using the perl debugger and put a watchpoint on the perl
> internal PL_tainted variable using the C debugger. Then continue
> to see where PL_tainted gets set.
>
> Alternatively sprinkle a few warn("PL_tainted=%d",PL_tainted);
> into the fetchrow_hashref code in DBI.xs.
Tim.
