in reply to Unsafe signals?

There's no real way you can modify the code above to make it safe. About the only thing you can do in a signal handler without safe signals is to change the value of a pre-existing, pre-allocated flag, eg
use vars '$flag'; $flag = 0; local $SIG{'TERM'} = sub { $flag = 1 } .... while (...) { ... die "got signal\n" if $flag; }
But that's probably not what you want.

The reason is that the signal could have been receieved at any point, such as in a malloc(), so any code in your handler that might trigger a call to malloc() isn't safe. Even my code isn't completely safe, but is perhaps, less unsafe.

Dave.

Replies are listed 'Best First'.
Re^2: Unsafe signals?
by cazz (Pilgrim) on Feb 23, 2005 at 17:09 UTC
    Michal Zalewski at BindView wrote a paper on exploiting signal handlers, http://www.bindview.com/Support/RAZOR/Papers/2001/signals.cfm

    dave_the_m is correct, you need to limit the functionality done in a signal handler as much as possible. Setting a flag is the probably the most accepted method for "safe" signal handlers.

    While your signal handlers are not perfect and can be used to hork your program quite badly, its nowhere near the worst signal handler I've ever seen. The "worst" signal handler I've come across was example:

    void ack() { env = getenv("DEBUG"); buf = malloc(256); strcpy(buf,env); syslog(buf); free(buf); longjmp FOO; free(buf); }
    a buffer overflow, print string vulnerability, a double free, and a longjmp. Take your pick for which you want to exploit :P