| Subject: | SQL::Statement incompatible with Perl taint mode |
It seems that if you try to create a SQL::Statement with taint-checking
enabled and use a tainted scalar to store the query (such as you might have
if your query came from CGI input), SQL::Statement fails to create the query
with a message like:
(in cleanup) SQL::Statement=HASH(0x######) is not a valid SQL::Statement
object at ./script line ##
Presumably, this is because SQL::Statement uses a subshell of some sort in
its processing. I would think it would be possible to replace this with
something more robust (something that would be Perl only, without depending
on the shell).
Searching the DBI users mailing list, I found a reference to this problem
in a short thread at http://www.xray.mpe.mpg.de/mailing-lists/dbi/2000-07/msg00637.html . The people who discussed it didn't seem to come up with any workaround other than using placeholders. I suppose the best workaround I can come up with is to explicitly check and untaint my query string, but the best way I can think of to do that is to parse it with an SQL parser to make sure it is valid! :) My statement doesn't modify the database at all, it's a simple SELECT.
I also upgraded to the latest SQL::Statement (version 0.1021) under Perl 5.6.1, and still got the error.
Executing the code under the debugger seems to prevent the bug from occurring! I know that 5.6.1 changed the behavior of the debugger in taint mode (it was basically impossible to use at <=5.6.0), and I wonder if that change can give a clue.
Here's a bare minimum test case to demonstrate the bug:
#!/usr/local/bin/perl5.6.1 -T
use warnings;
use strict;
use SQL::Statement;
my $ansi = SQL::Parser->new('Ansi');
my $query = $ARGV[0]; # use a valid SQL statement, like
# SELECT THISNUM FROM THISTAB
my $sql = SQL::Statement->new($query, $ansi);
I'm running under Solaris 6 and 8.