AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Yea, the only thing that should be writing files to the directory I'm checking is a custom built (not by me) ftp server. If I start encountering files that don't untaint easily, I've got real problems and will have to deal with it accordingly.

Thanks to everybody for the input.

db

($untainted) = $file =~ /^(.*)$/s;
[download]

The example you used ($filename=~/^(.+)$/; $file=$1;) breaks if there's a newline in the filename and if it doesn't successfully match the filename, you could be setting $file to something you do not expect (since an unsuccessful match leaves $1 to what it was set to before). Taint-checking probably wouldn't pick up on this mistake.

Yikes, newlines! Thanks. I forgot about the //s.

BTW, I make sure the $1 is localized by wrapping the regex in its own block. That's something I learned a couple months ago.

That ensures that the value of $1 from a successful match does not leak outside the block, but it doesn't protect you from $1 from an earlier successful match leaking into the block:

#!/usr/local/bin/perl -w

use strict;

$_ = 'perlmonks.org';

for my $re (qw/monks minks/) {
  /(perl)/;

  print "$1\n";

  {
    # new block for regex
    /($re)/;
    print "$1\n";
  }
}
__END__
perl
monks
perl
perl
[download]

It's generally necessary to check whether a regex succeeded before using any of the regex special variables.

Well, I wouldn't match "anything" but if you know what the format is roughly going to look like, you could limit it to something like this:

if ($filename =~ m#^[\w.]$#) {
  print "Ready to process $1...\n";
}
else {
  print "Skipping $1: bad characters detected\n";
  ## Log to a file, email someone, raise a ruckus, etc.
}
[download]

One reason to "taint check" filenames, particularly if the starting directory must be writeable by people or scripts that you can't necessarily trust, is to contain damage by preventing hacked filenames from moving downstream where they might be handled by other scripts or applications.

So it looks like what you need is a regex that will sanity check a filename given some set of rules for whatever platform you're on. (E.g., don't allow shell metacharacters).

You haven't said what you need to do if a filename flunks checking. Delete it?

if ( $filename =~ m/^(?:[A-Za-z0-9.])*$/ ) {
   rename $filename, "$newdir/$filename" or die "rename $filename: $!";
} else {
   unlink $filename or die "unlink $filname: $!";
}

But, you do know the filename. You have to know the filename in order to know that it doesn't match the pattern you want files in this directory to be named. After that, take AgentM's advice and just move it, unless the directory is world-readable.

ALL HAIL BRAK!!!

The program knows the filename, but I can't anticipate all permutations in advance (so I can write a tight regex) and a filename from a readdir must be (I'm pretty sure) untainted before I can move it (assuming I have Taint warnings turned on).

But like I mentioned above, since the directory I'm reading from is supposed to be reasonably secure, if I start encountering really weird filenames, I have bigger problems than just untainting.

thanks

The program knows the filename, but I can't anticipate all permutations in advance

I'm not sure about the taint feature in this respect, so I'll refrain from commenting further on that issue. But with the filename, when I say you do know the filename, it is in relation to the script. IOW, your spec seems to state that you do know the format of the filename, but not the filename.

But in order to compare the filename to a regex, you (the script is simply an extension of you; be the script :) have to know the filename. The regex shouldn't check all permutations of the name. It should check valid permutations.

In which case, you can write a very tight regex, since it is based on your valid filename. I think you're taking too many variables into account here with the solution of your problem. I see a single variable: the filename, and a single control: the format the filename should match. This makes it a very binary operation. It matches or it doesn't. What is it that I'm missing in this discussion? (This is purely discussion, since it seems as though someone may have provided a solution that you will use.) I'm interested in case I ever see this problem myself.

ALL HAIL BRAK!!!

elwarren brings up a good point about checking to see whether the file is still in the middle of being ftp'ed by another process. If you are on a unix (or Solaris, Linux, etc.) box, check out the fuser command. See your local manpage for more info on it.

Sometimes I get around this by writing out a second file after the first is completely written. Then the process polls the directory looking for filename.whatever.done When the .done file shows up I know it's safe to move the file I actually want.

Reading some fresh posts it looks like you're grabbing files from a custom ftp server, so this really isn't a solution for your problem...