Got it. Yeah, I'm running it from the command line: 'perl filename'

I take it this also means that if I call this script using Perl's 'require' command, the script will work in that situation, too. Great.

For running an external script it is generally better to use do.

But better still would be to wrap what the script does in some well-named functions, require the script, and then call the functions as needed. See also package and Exporter for standard ways of doing that and having the functions in the script not unexpectedly conflicting with your own functions...

I changed the above file to 544 (r-xr--r--). I am able to access and submit the Perl .cgi script (it's a form) with the browser. How is it possible a browser can do this with only the user's executable permission turned on?

Thanks.

You need to understand the architecture here.

The browser asks the webserver to do something.

The webserver realizes that to do it it needs to run your script.

The webserver runs your script (passing it information through the CGI protocol).

Your script sends the webserver text.

The webserver returns that text to the browser.

The browser does not know the CGI script is there. While the CGI script may guess there is a browser there, it doesn't really know that, it only knows about the webserver. And the operating system only knows how to help the webserver chatter to the outside world, and that the webserver can run your script.

So the short answer. The browser can do whatever the webserver is willing to do on its behalf, and as long as the webserver can run your script, that includes running your script. Conversely if you don't want the browser to do something (like run the Perl interpreter directly) you need to take that up with the webserver. (Which is why it is a really bad idea to put perl in your cgi-bin.)

I've been known to put the following code in a script in an attempt to guarantee it not be run from a browser.


localonly();
...
...
...

sub localonly {
   if ($ENV{'SCRIPT_FILENAME'}) {
      die "localonly -- $ENV{'REMOTE_ADDR'}";
   }
}
[download]

This seems to work.
But, I'd be curious if there's any feedback on exploits which can get around the SCRIPT_FILENAME or perhaps a better way to do this.

Claude

OK. It's just that I've seen scripts that refuse to run unless they have user, group, and other exectuables checked. This is what is confusing me. I'll keep banging away at this and get it figured out somehow.