Where do -T warnings go?

[Koos Pol]

Hello all,

I ran into this resentful qx($cmd) problem on 5.8.0 in tainted
mode. It took a very long time before I got to figure out it was
a taint issue because I couldn't find the taint warnings back:
not in $?, $!, $@, webserver error log or syslog. Is taint a
special case here?

Thanks,
Koos

 

[James Willmore]

I ran into this resentful qx($cmd) problem on 5.8.0 in tainted
mode. It took a very long time before I got to figure out it was
a taint issue because I couldn't find the taint warnings back:
not in $?, $!, $@, webserver error log or syslog. Is taint a
special case here?

When running a script in taint mode, you need to do such things as set
your PATH and escape metacharacters. This is documented in
perldoc perlsec
and
http://www.w3.org/Security/Faq/www-security-faq.html

As far as getting errors about insecure dependencies, you *should* get
them like any other warnings and errors. Best bet is to test your
script at the command line first to insure *most* possible issues are
taken care of before running the script through the web server.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Hofstadter's Law: It always takes longer than you expect, even
when you take Hofstadter's Law into account.

 

[Koos Pol]

James Willmore wrote (Wednesday 17 December 2003 15:46):

When running a script in taint mode, you need to do such things
as set
your PATH and escape metacharacters. This is documented in
perldoc perlsec
and
http://www.w3.org/Security/Faq/www-security-faq.html

Yes, thanks, I've studied these. Well, only perlsec to be honest.

As far as getting errors about insecure dependencies, you
*should* get
them like any other warnings and errors.

One SuSE 7.3 (5.8.0) they do get back (through STDERR). When
running on RedHat (also 5.8.0) qx($cmd) just seems to die without
leaving any trace anywhere.

Best bet is to test
your script at the command line first to insure *most* possible
issues are taken care of before running the script through the
web server.

That is very true. I should've.

HTH

Thanks for your remarks.

 

[James Willmore]

James Willmore wrote (Wednesday 17 December 2003 15:46):

One SuSE 7.3 (5.8.0) they do get back (through STDERR). When
running on RedHat (also 5.8.0) qx($cmd) just seems to die without
leaving any trace anywhere.

Well, one other "tool" you could use is the CGI::Carp module.

use CGI::Carp qw(fatalsToBrowser warningsToBrowser);

Or, whatever way you'd like to use CGI::Carp. Just be sure to remove
the *ToBrowser imports when running in a production environment. This
may help track down whatever issues you're running into.

However, as a general rule, you should run your scripts at the command
line first, then through the server. My guess is that you're running
into a suexec issue if you're using Apache. If that's the case, you
get nothing in the browser or the error log. However, you will see
something in the suexec log file.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Smoking is one of the leading causes of statistics. -- Fletcher
Knebel

 

[Koos Pol]

James Willmore wrote (Thursday 18 December 2003 10:34):

[well taken and appreciated advise snipped]

My guess is that you're
running
into a suexec issue if you're using Apache. If that's the case,
you
get nothing in the browser or the error log. However, you will
see something in the suexec log file.

That's a new one. I didn't figure that one out yet. Will look into
that. Thanks!