in reply to Re^2: Calling perl from CGI
in thread Calling perl from CGI

$result  = `/usr/bin/perl -v`;

does not contain user-supplied input. User-supplied input is what security-conscious hosts forbid. See perlsec for how it works.

Updated:

As other respondents have shown, your method would be ineffective even if it did not breach security, so I have deleted my original suggestions for putting an untainted module name between the backticks. The eval "use $module; 1" suggestion from lamp, besides having the advantage of actually working, is free of security concerns.

Replies are listed 'Best First'.
Re^4: Calling perl from CGI
by Anonymous Monk on Sep 07, 2008 at 07:55 UTC
    is free of security concerns.
    Not really :) $module is still tainted, and can be abused in the same way ('strict; system qw[ rm -rf / ];')needs to be validated, something like 
    $module = $1 if /^([a-zA-Z_][a-zA-Z_0-0]*(?:(?:'|::)[a-zA-Z_0-0]+)*)$/
+s;
# or

$module = $1 if /\A[^\W\d]\w*(?:(?:\'|::)\w+)*\z/s;

    [download]
[reply]
[d/l]
[select]
Re^4: Calling perl from CGI
by Anonymous Monk on Sep 07, 2008 at 06:20 UTC
    Please see Re^3: Calling perl from CGI
    That approach is fundamentally flawed because it relies on capturing STDOUT, when nothing ever gets printed to stdout.
[reply]

In Section Seekers of Perl Wisdom