CGI/Perl prob

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

i have a little problem with my CGI/perl script. So here it is: i try to open de stdout of this Unix command line and print it:

cat $filename | extract-info
[download]

where $filename is the name of the file (dah!) and extract-info is a program i coded and compiled in java (not in bytecode, but in native machine code, using gcj). Somehow, it seems like my script can't find my program, even thought it is located in the same directory as my cgi script, and that the permissions are adjusted (-rwxr-xr-x). here is the part of the script that is supposed to do the job:

$output=`cat $filename | extract-info`;
print($output);
[download]

i am also sure that my program works, because the same code lines work if i use them in a normal Perl script context (i.e. not via an html form). thx in advance

Comment on CGI/Perl prob Select or Download Code

Replies are listed 'Best First'.
Re: CGI/Perl prob by dsheroh (Monsignor) on May 28, 2002 at 19:33 UTC
nix systems frequently omit . (the current directory) from the path and CGI environments may not have a path at all. (Both of these, by the way, are Good Things for security.) Now that we know why you have this problem, how to fix it? `$ENV{'PATH'} .= '.';` - Should work, but leaves you vulnerable to trojan executables in the current directory. Probably not a real good idea. $output=`cat $filename \| ./extract-info`; - Also should work, but leaves you at the mercy of where your current directory is. Could cause problems later if things get moved around. $output=`cat $filename \| /full/path/to/extract-info`; - This is a nicely robust way of doing it and is the way that I would opt for. Also, `taint` is your friend - especially if you're doing things like `cat $filename`! Update:* Corrected #1. For some reason, I originally showed how to add . to `@INC` instead of `$ENV{'PATH'}`. Must be lack of sleep...	[reply] [d/l] [select]
Re: CGI/Perl prob by Ovid (Cardinal) on May 28, 2002 at 19:28 UTC
Some background. This was originally in an email sent to me and I sent this person here because I didn't see the problem offhand. Here's the snippet that he's trying to run: `open(TMP, " cat $filename \| extract-line \|") \|\| die "Can't open SILC p +rocess"; $output = join("\n", <TMP>); close TMP; print($output);` [download] However, I didn't notice the last line: i am also sure that my program works, because the same code lines work if i use them in a normal Perl script context (i.e. not via an html form). If I understand what is written here, that means this runs from the command line but not from an HTML form. My question: are permissions set correctly? Your Web server will typically execute CGI scripts with lower permissions than you will have from the command line. This could be causing the problem. Quick question: where are you getting the `$filename` from? This could be a security hole if you're getting the name from the Web form. Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply] [d/l]