Tim Bunce wrote: > On Tue, Dec 15, 2009 at 02:53:03PM +0000, Martin Evans wrote: >> If you are using the latest DBI and Perl 5.10.0 or 5.10.1 and running in >> taint mode (but have not set DBI's Taint, TainTIn, TaintOut) then use >> tainted strings in the SQL you issue the resulting data is tainted. All >> we were doing is adding $0 as a comment to the end of the SQL e.g., like >> this: >> >> select * from table -- myprogram.pl >> >> but $0 is tainted and so all data coming back from the select is tainted. >> >> We moved our application from Perl 5.8.8 to an ubuntu box running 5.10.0 >> a few weeks ago but did not notice this problem until late last week. >> This did not occur for us on 5.8.8 on another machine. >> >> I've no idea what is tainting the returned data but this is reproducible >> for us here is a small amount of perl. > > From memory, perl tainting works on a per-statement basis. If a tainted > value is accessed during a statement then any new values created by that > statement are marked as tainted. The 'tainted value seen' flag gets > reset for each statement. > > So I'd guess that you're using a single statement, like a select*_* > method, to pass the (tained) SQL in and get the result data back. > > Tim. > >
I saw that "single statement" mechanism you refer to and there are references to it in DBI.xs too. I presumed it was talking about perl statements and not DBI statement handles. However, in this case I was not using a perl single statement I was doing (and can continue to demonstrate): prepare($sql) <-- tained data went in here execute fetchall_arrayref Also, I continue to do the same thing I always have in 5.8.8 with the same module versions where this does not happen so I'm really saying something seems to have changed between 5.8.8 and 5.10 and possibly in Perl itself. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
