Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 May 2015 11:35:25 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Signal handling within john formats.

Hi Sayantan,

On Thu, May 28, 2015 at 03:23:27PM +0530, Sayantan Datta wrote:
> On Wed, May 27, 2015 at 1:01 PM, Sayantan Datta <std2048@...il.com> wrote:
> > I'd like to use signal handling functions - alarm() and sigaction() within
> > a format.

As you're probably aware, you should not.

> > Howver using them disrupts status checking, even if I restore to
> > the previous signal handler after I'm done using signals.
> >
> > The sequence of function calls within the format is as follows:
> >
> > sigaction(SIGALARM, &set_signal, &old_signal);
> > alarm(x);
> > .
> > .
> > .
> > alarm(0);
> > sigaction(SIGALARM, &old_signal, NULL);
> >
> >
> > But the above sequence fails to restore normal JtR signal handling. So,
> > what's missing?

> Turns out restoring previous signal handler is not enough; alarm() function
> interferes with setitimer() function. So, set setitimer() must also be
> saved before using alarm() and then restored after calling alarm().

How exactly setitimer() interacts with alarm() may vary across systems.
You should not mix them.  You may do what you need with setitimer()
alone, but even then you still have a race condition between replacing
the signal handler and replacing the timer settings (and ditto when
restoring them).  To avoid it, you may block/unblock the signal.  Once
finally implemented correctly, this should actually work... but it gets
complicated.  As an alternative, you could add support for registering
of your additional handlers (or just one additional handler) to the
global alarm handler in JtR.  This would be JtR-specific, which is good
in that it won't introduce dependency on extra features of the
underlying system working correctly.

Better yet, though, you'd avoid the need for this.  Why exactly do you
need it?  Let's discuss the actual problem you're trying to solve first.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ