Running perl

Isn't Perl a security risk?

Now, back when Perl first started being used on Wintel web servers, some bad advice was given out, and perl.exe got placed in the cgi-bin directory. This was a very insecure thing to do. The perl scripts should be stored separately from the Perl interpreter (the exe or the dll), to stop miscreants invoking the interpreter with their own parameters instead of your scripts. Put the interpreter in a directory which is not served to users via a virtual root.

Despite that, Perl's fine. If anyone has any proof otherwise, I'd like to know.

Perl also has the "taint" mechanism, which means that all data supplied by the user is subject to restrictions on what you can do with it. This feature was designed to allow programmers to write setuid-root scripts for UNIX (ones which were runnable by anyone, but ran with administrator privileges), but it extends to web scripts too.

In the final analysis, Perl is as secure as the script written by you, the programmer. If you're sensible, perl won't let you down.

IIS4 won't invoke Perl on my scripts.

1. In the Management Console, select your web site.
2. Pull up Properties.
3. Go to the Home Directory tab.
4. Click on Configure...
5. Select the App Mappings tab

This is where you say that .pl files are handled by C:\perl\bin\perl.exe. I've got the following command:

C:\perl\bin\perl.exe %s %s

These parameters require some extra attention:

1. They're lower-case. %s will work; %S won't. Check this.
2. There should be two. The first specifies the script to perl, and the second is there for when your script is called with a GET, and the query string is passed as a parameter instead of via stdin.
3. Bizarrely, I've had at least one report of two %s parameters causing perl to break, not work. If you're having problems, by all means try it with a single %s. This report was from someone who had, I think, installed a Service Pack too, though.

   You should also mark this entry as being a Script interpreter. This means that your directory with all your .pl scripts in can be marked as having Script permission, not Execute permission; that way, it's safer.

   It's a good idea to select the option to make IIS4 verify that the .pl file exists before invoking Perl (I'm kinda scared that it doesn't, anyway....).

   Leave the Method Exclusions field blank, so that your scripts can accept GET and POST requests (and HEAD, PUT and DELETE, if you're bothered about them).

   A side note: you shouldn't have the perl.exe file visible in any directory which has Execute permission, as far as the web server is concerned; to do so means that anyone can run their own scripts on your machine.

   Perl can't run .cgi files

   .cgi, .pl, whatever. My convention is to call perl scripts with a .pl extension. If you've used .cgi, then pretend I've written .cgi everywhere you see .cgi, and read the rest of this FAQ. In particular, if you've got ActiveState's version of perl, check what they default to as the extension (I don't have their dist, so I don't know; they've probably got both covered by default).

   Perl can't call other Perl scripts.

   It can - it just depends on how you call them. I've got Edit with Notepad as the default association for .pl and .pm files, so clicking on them in NT Explorer allows me to edit the files. The problem is, if you then have in your Perl scripts:

   system('\path\to\script.pl')
   

   You'll find that Notepad (or whatever) will start up in the background. Not nice. On NT, always invoke other Perl scripts using:

   system('c:\perl\bin\perl.exe \path\to\script.pl')
   

   (of course, if you can eval the script instead, that's better)

   ---

   Steve Kilbane. Whitecrow home.