in reply to CGI Script Calling Grep

muleherd,

What does it display? Do you get an internal server error? (probably not) Do you get a "page cannot be displayed?" My only concern with this code is that you could timeout before the recursive grep starts to output any data. If you have access to your servers conf file, check out the "Timeout" value. Combine that with mandog's (Re: CGI Script Calling Grep) suggestion that '.' may not be where you think it is (and with all the other security tips) and you should have a solution.

-derby

Replies are listed 'Best First'.
Re: Re: CGI Script Calling Grep
by muleherd (Initiate) on Sep 26, 2001 at 23:30 UTC
    derby,
    The page loads, but it doesn't have the output of grep. Everything before and after where the grep command should be IS there. '.' does in fact seem to be referring to the correct directory. I was able to successfully grep another script in the same directory by altering my exec command. Is it still necessary to untaint the user string when passing the parameters to exec as a list, avoiding the shell?
      Try this theory on for size:

      You're running this on an OS like Solaris, where the standard version of grep doesn't provide a -r option. Your system administrator has installed GNU grep (which does have this option) in /usr/local/bin or some such place.

      When you run the script yourself, your PATH contains /usr/local/bin so the script uses GNU grep. When the web server runs your script, it gets a different path and ends up running /usr/bin/grep. This version just complains and exits, but you don't see the error message.