On Wed, Feb 12, 2003 at 12:52:25PM +0000, Tim Bunce wrote:
> On Wed, Feb 12, 2003 at 10:57:29PM +1100, Bradley Baetz wrote:
> Thanks for digging into this!
>
> Here's something I wrote previously that may give some ideas:
Hmm. In what context was this written? :)
> > 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.
Unfortunately, the perl5.005 I'm using isn't a debug build. However, I
think I know where its coming from:
if (DBIc_is(imp_sth, DBIcf_TaintOut)) {
dTHR;
TAINT; /* affects sv_setsv()'s called within same perl statement */
}
Thats where the out tainting happens - theres that if (... && 0) bit in
the dispatcher which is replaced by this. I remmebr I worked out why
when I worked on this patch originally, but I can't remmber now :)
If I add those warn lines arrond the TAINT;, then I get:
-> fetchrow_hashref in DBD::_::st for DBD::ExampleP::st
(DBI::st=HASH(0x823b2bc)~0x823a0d0)
1 -> fetch for DBD::ExampleP::st (DBI::st=HASH(0x823a0d0)~INNER)
XX:
PL_tainted=0 at blib/lib/DBD/ExampleP.pm line 348.
PL_tainted=1 at blib/lib/DBD/ExampleP.pm line 348.
1T <- fetch= [ '16877' '4096' '.' ] row1 at 10examp.t line 323
Insecure dependency in parameter 1 of NAME_uc->FETCH method call while
running with -T switch at t/10examp.t line 323.
with a lots-of-debug-lines DBI.xs and trace level 2 set. Line 348 of
ExampleP.pm is: $sth->_set_fbav(\@new); and the XX: before shows that
$new[1] isn't tainted before calling that.
> >
> > Alternatively sprinkle a few warn("PL_tainted=%d",PL_tainted);
> > into the fetchrow_hashref code in DBI.xs.
>
I tried adding a TAINT_NOT to the end of _get_fbav, but that didn't
help.
Adding one to the end of _set_fbav didn't either.
The best I can do in gdb ATM is that the final PL_tainted set happens
after the call to _set_fbav returns (specifically, after a |warn| after
the ST(0) assignment in _set_fbav, with a stack of
#0 0x08080770 in Perl_magic_gettaint ()
#1 0x0807e78b in Perl_mg_get ()
#2 0x0808bf48 in Perl_sv_2bool ()
#3 0x402051e9 in XS_DBI_dispatch (cv=0x81ae8f8) at DBI.xs:2359
#4 0x080894d8 in Perl_pp_entersub ()
#5 0x080599ec in perl_call_sv ()
#6 0x08059600 in perl_call_method ()
#7 0x40208f4b in XS_DBD_____st_fetchrow_hashref (cv=0x812dee4) atDBI.xs:3467
#8 0x40204f61 in XS_DBI_dispatch (cv=0x81b22fc) at DBI.xs:2322
where frame 3 has meth_name 'fetch'. Line 2359 of DBI.xs in my modified
version is:
**** here if (SvTRUE(DBIc_ERR(imp_xxh)))
PerlIO_printf(logfp," !! ERROR: %s %s\n",
neatsvpv(DBIc_ERR(imp_xxh),0),
neatsvpv(DBIc_ERRSTR(imp_xxh),0));
I'm not entirely sure that thats right, though. I should probably try a
DBI.so without optimisation tomorrow.
> Tim.
Bradley
