openssh unix dev - Mar 2006 - sshd blocking SIGALARM turns out to be due to tcpd

Ian Jackson:
> I recently encountered a bug where some ssh login sessions would
> apparently inherit a blocked SIGALRM.  A web search showed up two
> relevant threads:
>  http://lists.suse.com/archive/suse-linux-e/2005-Dec/2628.html
> 
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113533337923128&w=2
> et seq - but sadly no answers.
> 
> Experimentation with strace et al revealed the problem: the
> tcp-wrappers build I was using would use alarm(2) to time out of the
> ident (RFC931/1413) lookup, but failed to properly use sigsetjmp.  I
> was using (basically) the Debian package (describing itself as version
> `7.6.dbs-8'), which had been patched to use sigsetjmp instead of plain
> setjmp but passed 0 for the 2nd argument.  Changing it to pass 1 made
> it work.
> 
> I have reported this bug to the Debian BTS and they will no doubt be
> passing it upstream more formally eventually, but I thought that since
> this problem is so mysterious I would document at least one possible
> cause in places where the symptoms had been seen already.  See:
>  http://bugs.debian.org/354855
> which contains a patch.
This could be introduced by third parties. The tcp wrapper does this:

        if (setjmp(timebuf) == 0) {
            signal(SIGALRM, timeout);
            alarm(rfc931_timeout);
	    ... stuff ...
            alarm(0);
        }

Thus,  no dangling signal handlers.

	Wietse

Ian Jackson:
> Wietse Venema writes ("Re: sshd blocking SIGALARM turns out to be due
to tcpd"):
> > Ian Jackson:
> > > Experimentation with strace et al revealed the problem: the
> > > tcp-wrappers build I was using would use alarm(2) to time out of
the
> > > ident (RFC931/1413) lookup, but failed to properly use sigsetjmp.
[...]
> > 
> > This could be introduced by third parties. The tcp wrapper does this:
> >         if (setjmp(timebuf) == 0) {
> >             signal(SIGALRM, timeout);
> >             alarm(rfc931_timeout);
> 
> Indeed the broken use of sigsetjmp was introduced by third parties (I
> can see in the Debian diff that the original uses setjmp).  But, I was
> very surprised to see you still using signal.
In code that was released in 1996.
>  Reading SuSv3 (the best
Sure.

	Wietse
> reference I have available) doesn't make it clear whether the code
> above guarantees to unblock SIGALRM if the code longjmps out of the
> handler; this code is relying on old BSD and SysV behaviour, which
> AFAICT is as you might hope but I can see why people might be
> confused and try to `fix' it by changing it to use sigaction.
> 
> Thanks,
> Ian.
>