Troubleshooters.Com Presents

July 1999 Troubleshooting Professional Magazine: Troubleshooting CGI

Copyright (C) 1999 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

<--Troubleshooting Review   |  Contents   |   Due Diligence: Do It On Your Linux Box First-->

CGI Troubleshooting On Someone Else's Server

By Steve Litt
Life is easier for those of us lucky enough to have access (especially root access) to the web server. We simply run the script, with a proper input piped in, at the command line. Once it works with our own userid, we can test it using a different user id to simulate the http interface. The error messages we see point us right to the problems, which we can then fix either in the code or in file and directory permissions. Not trivial, but certainly not prohibitively difficult.

But now consider the webmaster not allowed physical, terminal or telnet access to the server. The CGI program can be run only from the browser. Error messages, which are sent to stderr instead of stdout, are invisible. Locations of needed interpreters such as Python and Perl are unknown. The true nature of a CGI form's transmission to the server is unknown (this is true even when you own the server).

Under these conditions you're restricted to the following two obvious testpoints:

  1. You can modify the information typed into the form and observe any symptom changes.
  2. You can use sophisiticated telnet clients to observe files and directories, and their permissions and owners.
It's like trying to fix a radio without a voltmeter. An earlier sentence in this magazine issue bears repeating:
 
When a reproducible problem, on a well defined system, having a reasonable amount of readable test points, is investigated using a valid Troubleshooting Process, solution is a mathematical certainty.

What's the name of a system lacking a reasonable amount of readable test points? It's called a black box, and we all know black boxes cannot be troubleshot, only manipulated with trial and error or replaced. We *must* have a reasonable amount of readable test points.

Why in the world would the system administrator deny you, a paying customer, the telnet access so necessary to troubleshoot CGI? It's simply that telnet is a security risk so blatant that even the smartest webmaster cannot fully protect you and the others using the system from script kiddie exploits. A good way to view it is as a hockey game, with your sysadmin is the goalie. The other team consists of thousands of honest users, who do nothing but skate around and occasionally block the goalies view, and tens or hundreds of crackers determined to whack that exploit puck past the goalie. Allowing telnet is like quadrupling the size of the goalie cage. Dangerous.

Fortunately, the The CGI Troubleshooting Toolkit article later in this magazine gives you tools to replace those removed by your lack of telnet and root access. These tools are so powerful that you'll find it easier to troubleshoot than using telnet. These tools give you a clean diagnostic path to follow.

The CGI Diagnostic Path

  1. Ask your webmaster the location of the sh shell, or find it by trial and error.
  2. See if *any* CGI script can run in the directory in question.
  3. Find the location of Perl, Python, or whatever you're using for CGI.
  4. See if a Perl (or whatever you're using) CGI program can run in the directory, after ascertaining that the top line points to the correct interpreter.
  5. Find the server's web http username, and its access to files and directories, its executable path.
  6. View the CGI program's error messages.
  7. See exactly what your browser form is passing to the CGI program.
  8. If necessary, see if the CGI program can write to the desired directory (on CGI programs which write files).
Combined with the CGI Troubleshooting tools provided later in this Troubleshooting Professional issue, this diagnostic path can result in a quick and accurate fix. And since debugging is CGI development's bottleneck, this enables rapid CGI development.
Steve Litt can be reached at Steve Litt's email address.