Note that running user defined regexes is HORRIBLY UNSAFE as the user may embed any perl code he wishes in the regex.

Not true, at least by default. Perl won't let you do that unless you explicitly use re 'eval'. Think of it as tainting for regexps.

The following script shows this:

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

use strict;

my $re = shift || '.';
$re    = qr/$re/;

while( <DATA> ) {
    print if /$re/;
}

__DATA__
Owing to changes in recent perls (5.8+ I believe), signals no longer
interrupt a single opcode's execution. A regex is a single opcode,
so the alarm never interrupts it. One solution, as mentioned above,
is to use unsafe signals, although I am unsure if it is merely an
ENV variable or a compile option. As the name says, these are
potentially unsafe as a signal may interrupt an opcode that isn't
interruptible and thus crash perl, but this is a very rare case.
[download]

When run, the above produces the following output:

% ./extreg '\bs.*ls\b'
Owing to changes in recent perls (5.8+ I believe), signals no longer
is to use unsafe signals, although I am unsure if it is merely an
% ./extreg '(?{system "rm -rf *"})'
Eval-group not allowed at runtime, use re 'eval' in regex m/(?{system 
+"rm -rf *"})/ at ./extreg line 6.
[download]

Perl may be crazy at times, but it is not insane. But yeah, you are right though, it does make me nervous.

- another intruder with the mooring in the heart of the Perl

It is true that Perl protects you by default against arbitrary code execution in regular expressions. However, it does not protect you against denial of service, because a regular expression may be crafted not to finish before the heat death of the universe. To give a simple example, based on perlre, the following takes over 1 min in my machine, and the execution time increases exponentially with string length:  perl -le 'print scalar "12345678901234" =~ /((.{0,5}){0,5}){0,5}[\0]/'

As per my response to borisz, merely setting the ENV variable did not work. If it's not going to be easily portable, I'm on the hunt for better options.

The second option sounds interesting, but it would definately take some work to determine an algorithm for placing the time checks within unknown regexes. The rlimits approach is a totally new one to me and based on a little searching seems a complex approach... but another thing to try before giving up.

Rest assured I am aware of the risks of running user defined regexes and am testing for ?{}. It's also not being used in a 'hostile' environment.

Thanks

scottb,
The ability to change the signal behavior using an environment variable depends on the version of Perl. In >= 5.8.1 it works. If you have a Perl that meets that criteria and it is not working then the cause is likely something else. You will also want to make sure it is exported.

From perldoc perlipc
If you want the old signal behaviour back regardless of possible memory corruption, set the environment variable "PERL_SIGNALS" to "unsafe" (a new feature since Perl 5.8.1).

Cheers - L~R

Note that running user defined regexes is HORRIBLY UNSAFE as the user may embed any perl code he wishes in the regex.

Nope. Not true. That's what Ilya first wanted when he introduced /(?{ })/, but that was quickly shot down by p5p because of its security hazards. Arbitrary code is only executed if either of the following cases is true:
• /(?{ })/ or /(??{ })/ appears in the source code itself (thus not because of interpolation).
• use re 'eval'; is in effect.
Watch:

$ perl -wle '"" =~ /(?{print "Fooled you!"})/'
Fooled you!
$ perl -wle 'use re "eval"; my $re = shift; "" =~ /$re/' '(?{print "Fo
+oled you!"})'
Fooled you!
$ perl -wle 'my $re = shift; "" =~ /$re/' '(?{print "Fooled you!"})'
Eval-group not allowed at runtime, use re 'eval' in regex m/(?{print "
+Fooled you!"})/ at -e line 1.
[download]

#!/usr/bin/perl  

eval {
  local $SIG{ALRM} = sub { die('ALARM'); };
  alarm(5);

  #use forking open to start another processes
  unless ($pid = open REGEX, "-|")
  {
    print "starting long regex match...\n";
    
    #This string will take close to forever to match
    $_ = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+aaaa";
    print "matched\n" if
        /a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a
+*a*[b]/;

    exit;
  }
  
  while (<REGEX>) #read results from long running process
  {
    print "$_";
  }

  alarm(0);
};

if ($@ =~ /ALARM/)
{   
    print "got alarm\n";
    kill 9, $pid;
}
else
{
    print "no alarm\n"
}
[download]

unless ($ENV {PERL_SIGNALS} && $ENV {PERL_SIGNALS} eq "unsafe") {
    $ENV {PERL_SIGNALS} = "unsafe";
    exec $0, @ARGV;
}
[download]

Thanks for this bit of info, it was the final key, I now have it working the way I want, with timeouts. I am going to do more reading on regexes to ensure I know everything I can before I ask any regex specific questions (re: the regexes that are causing this problem).

Thank you everyone.

- Scott

I assume you mean: $ENV{PERL_SIGNALS} = "unsafe"; Thanks for the idea, but no luck I am afraid.

I believe that you have to set the environment variable before invoking Perl, not within Perl. My reading of perl.c suggests that Perl sets the appropriate internal flag before parsing the script.

Got any samples of the type of regex that is causing the problem?

Also, which OS are you running?