[Pdx-pm] [csieh at fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl]

[J. Shirley]

On Tue, Aug 26, 2008 at 11:50 AM, Aristotle Pagaltzis <pagaltzis at gmx.de> wrote:
> * Daniel Johnson <teknotus at gmail.com> [2008-08-26 20:15]:
>> > The next important step is to always invoke perl with:
>> > #!/usr/bin/env perl
>> > Do not use:
>> > #!/usr/bin/perl
>>
>> The /usr/bin/env trick has significant security considerations.
>> Consider a cgi example.
>>
>> http://example.com/cgi/submit.pl?PATH=/tmp
>>
>> Which would run whatever is called perl in the temp directory
>> instead of calling the real perl to compile, and run the cgi
>> script.
>
> Not hardly, at least not with any sane web server. CGI is not
> PHP. All you will manage to do with that `PATH=/tmp` query string
> is to, well, put `PATH=/tmp` in the `QUERY_STRING` environment
> variable. You will most emphatically *NOT* manage to put `/tmp`
> in the `PATH` variable – unless you're using an insane web server
> that actually implements CGI that way. But then the problem is
> still not on the Perl script's shebang line.
>
> That said, your basic point is quite correct: using `env` on a
> system with multiple perls is unwise, as it introduces a random
> external influence on which perl will execute.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>


I really wouldn't call it "random" - it is external influence, but
that is somewhat the point of having multiple perls.  If we're talking
about a single replacement for your system perl it probably isn't
necessary.

If you truly want multiple perls, in my opinion env is the best way to
manage it.

(And now I'm just more thankful that I do not deal with PHP... no
wonder so many PHP sites are exploited)