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

Unfortunately this is probably not a brain teaser for you guys but i am stumped as a new perl user. The purpose is simple...to tell perl to go to a specified directory and unzip a specified file. I have an html form that is executing a perl script. I am trying to use the html variables inside the perl. I can print them...so i know i am getting them inside the script...but when i use them in a command.. they dont work...if i hard code the text with the command they work. So i am assuming for some reason perl is not evaluating the variable as its contents when used in the script. What am i doing wrong? Here is the html 
<?php
//upload and unzip a package
//this file needs to be in adminstrator folder
//and the unzip.cgi needs to be in the cgi-bin folder

if(!isset($_POST['upload'])) {
    echo " This program uploads a zip file via ftp to a server <br>";
    echo " In a particular directory and then unzips it there <br>";
    echo " Usage:  dir = directory you want it in <br>";
    echo " Example:  /frog/dog/cat  <br>";  
    echo " Usage:  zip = the zip file you want uploaded and unzips <br
+>";
    echo " Example:  phpwcms_1.3.3.zip  <br>";  
    echo '
    <form name="upload"   method="POST" action="http://mydomain.com/cg
+i-bin/undone.cgi">
    dirname<input name=dir size=55> <br />    
    zipname<input name=zip size=55> <br />  
    <input type="submit" name="upload" value="Upload">
    </form>
    ';
} else {

  } 
?>

[download]
Here is the perl 
#!/usr/bin/perl -w
print "Content-type: text/plain\n\n";
use CGI;
my $query = new CGI;
my $dir = $query->param('dir');
my $zip = $query->param('zip');
## Here is the commands that wont work
cd $dir
unzip $zip
## Here i can print them...just fine
print $dir;
print $zip;

[download]
If i hardcode the values of dir and zip like this cd /dog/cat and unzip rat.zip they work just fine...

Replies are listed 'Best First'.
Re: HTML Form and Perl
by pc88mxer (Vicar) on May 07, 2008 at 17:29 UTC
    If i hardcode the values of dir and zip like this cd /dog/cat and unzip rat.zip they work just fine...
    I am really confused by this. cd and unzip are not built-in perl functions. As kyle suggested, you normally would do something like this: 
    chdir($dir) && system("unzip", $unzip);

    [download]
    The && is there to make sure that the unzip command is run only if the chdir succeeds.

    However, since you are using these commands in a CGI script, you need to take extra precautions to make sure that users cannot subvert your script to make it do something you don't want them to do. That means you have to validate the input to make sure it looks like what you expect it to look like. For example, I'm sure you don't want users to be able to chdir to just any directory and unzip just any file.

    Perl has a nice feature called tainting which helps you keep track of user input which needs to be vetted before it can be passed on to commands like chdir and system. You can enable it using the -T switch in the she-bang line of your script: 

    #!/usr/bin/perl -T

    [download]
    When enabled, user input (like posted form data) will be marked as tainted, and if you try to pass the data directly to a command like chdir or system, perl will throw an exception. To untaint the data, you have to examine it with a regular expression: 
    my $dir = $query->param('dir');
my $zip = $query->param('zip');
die "invalid dir" unless ($dir =~ m/^([a-zA-Z0-9]+)\z/);
my $valid_dir = $1;  # $valid_dir is untainted
die "invalid zip file" unless ($zip =~ m/^([a-zA-Z0-9]+)\z/);
my $valid_zip = $1;

chdir($valid_dir) && system("unzip", $valid_zip);

    [download]
[reply]
[d/l]
[select]
      Well... i am about 75 and new to perl..so maybe i am confused :) BUT... when i hardcoded the perl script with the cd and unzip (as shown) and specified text not a variable... and executed the script by itself...it sure went to the right directory and unzipped the file...so...i just wanted to enhance that with a variable... It may have something to do with taint then...cause it only would not work with the variable... i will try your idea and see if that works. OLD MAN trying to learn :)
[reply]
        well unless i missed something... this code as suggested...ran...but did not do anything or produce any errors that i could find. plus when i try to print it...nothing prints... here is what i have coded. 
        #!/usr/bin/perl -T
print "Content-type: text/plain\n\n";
use CGI;
my $query = new CGI;
my $dir = $query->param('dir');
my $zip = $query->param('zip');

die "invalid dir" unless ($dir =~ m/^([a-zA-Z0-9]+)\z/);
my $valid_dir = $1;  # $valid_dir is untainted
die "invalid zip file" unless ($zip =~ m/^([a-zA-Z0-9]+)\z/);
my $valid_zip = $1;

chdir($valid_dir) && system("unzip", $valid_zip);

print $valid_dir;
print $valid_zip;

        [download]
[reply]
[d/l]
Re: HTML Form and Perl
by kyle (Abbot) on May 07, 2008 at 16:45 UTC
[reply]
Re: HTML Form and Perl
by hesco (Deacon) on May 08, 2008 at 02:43 UTC
    As for why your script is not producing any output, try instead: 
    print STDERR "my \$valid_dir is: $valid_dir \n";
print STDERR "my \$valid_zip is: $valid_zip \n";

    [download]
    And inspecting your logs at: /var/log/apache2/error.log for your output. Its likely because you did not create your html headers, but that may be off. If you are going to `use CGI;`, you could at least replace the printing of the Content-type: line with:

    print $query->header;
print $query->start_html('My Application');

    [download]
    Since that module is built to handle that sort of thing.

    Not sure of the true scope and purpose of your application, but I would go pc88mxer at least one more step down the path toward securing this app. I would urge that you not permit someone to simply name any old directory on your server where they are permitted to upload an arbitrary and potentially hostile zip file. I would choose a directory which I controlled and over which I could exercise some supervision. In fact, if you are running a web server, it makes alot of sense to create a disk partition from which an executable can not be executed. (See `man mount` for further details, and set your configuration for that partition in /etc/fstab). Then you can mount it to /tmp/uploads and use it as an additional layer of protection between your server and potentially hostile operators at a browser.

    I would start by trying (the untested): 

    my $safe_uploads_directory = '/tmp/uploads';
use Archive::Zip qw( :ERROR_CODES :CONSTANTS );
my $zip = Archive::Zip->new( $valid_zip );
chdir( $safe_uploads_directory ) && $zip->extractTree();

    [download]
    This follows one of the first rules of programming: laziness, by reusing other people's code. Adam Kennedy already figured out all this manipulating a zip file stuff for you. If you take a few minutes to read his documentation, with `perldoc Archive::Zip`, you might find it could save you hours of working this all out for yourself, as well as teach you more about the structure of a zip archive than you ever wanted to know. You might find that this works better for you.

    -- Hugh

    UPDATE:

    I corrected a typo to provide a complete and absolute path in my definition of the $safe_uploads_directory.

    if( $lal && $lol ) { $life++; }
[reply]
[d/l]
[select]
Re: HTML Form and Perl
by almut (Canon) on May 08, 2008 at 04:44 UTC

    I think what hasn't been mentioned so far is that the form doesn't have the elements that would make the browser actually upload the zipfile.  Maybe I'm misunderstanding things completely... but I thought I'd mention it — just in case... :)

    How is the file supposed to be transferred to the server? You say in your PHP code

    echo " This program uploads a zip file via ftp to a server <br>";

    Is that "ftp" to be taken literally? If so, what/who is performing the FTP transfer? Is this being done separately (manually) before the form is submitted? Or is the file meant to be uploaded via the browser / HTTP upon submitting the form?

    In case of the latter, there would normally need to be an <input type="file" ... >, together with the enctype="multipart/form-data" within the <form> tag.  In other words, as it is at the moment, one problem might be that nothing is really being uploaded, which would also explain why the unzipping doesn't work yet...

[reply]
[d/l]
[select]
      well i was writing the code in parts. So i just manually uploaded the zip file...to the server...just so i could test out that the unzip was working fine. Once i got that ok...i would add the file transfer. This is so basic a need (move a file to server and unzip it in a specified folder), i thought that it was well covered ground...but so far...no one has a solution that works that i have seen. BUT it is nice to know that i am not as stupid as i thought...or it would have been easy to do. :) Thanks for the interest and suggestions.
[reply]
        i was writing the code in parts ...

        That's fine. Actually, it's a good strategy in general. I just wasn't sure what exactly you were expecting to happen... so I mentioned it...

        This is so basic a need (move a file to server and unzip it in a specified folder), i thought that it was well covered ground.

        Yes... in fact, it shouldn't be too hard. And I think you're pretty close to having it working.  What seems to be the problem with your last attempt is that that untainting regular expression in 

        die "invalid dir" unless ($dir =~ m/^([a-zA-Z0-9]+)\z/);

        [download]

        is missing a slash in its character set [a-zA-Z0-9] — note you're validating a path. Maybe, you'll also want to add stuff like underscore, dash, etc.  I.e. something like 

        die "invalid dir" unless ($dir =~ m/^([\/\w-]+)\z/);

        [download]

        (\w is short for "alphanumeric", i.e. alphabetic character, digit and underscore)

        As you had it, your CGI script was most likely dying with an "invalid dir" message written to stderr, in case you had specified a path like /frog/dog/cat. So, nothing after that line in the script did execute... By default, the message would end up in the webserver's error log, but you change that by adding 

        use CGI::Carp 'fatalsToBrowser';

        [download]

        somewhere near the top of the CGI script. This would redirect fatal error messages to the browser, which is nice for debugging purposes (you might want to disable it again, once things are working...).  Good luck.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom