openssh unix dev - Dec 2005 - sshd blocks SIGALRM

Gidday everbody, 

We have just found an interesting issue regarding the sshd daemon on our
SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM as
shown in the /proc/pid/status:

$ cat /proc/`cat /var/run/sshd.init.pid`/status
Name:   sshd
State:  S (sleeping)
SleepAVG:       0%
[...]
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000002000  <-- SIGALRM is blocked
SigIgn: 0000000000001000

As a result, any descendent processes shall inherit this mask. The bad news
is that some commands rely on SIGALRM being unmasked, e.g. those invoking
alarm() or similar. If those commands are started from a "ssh shell",
then
they won't work correctly (e.g. never times out). That's really
annoying.

Do you have an idea where the problem lies?
Below you shall find the relevant information about the system. 

Thanks in advance! 
Loic. 

******************* System information ******************

* Hardware:
HP Proliant, intel PIII 1.4Ghz

* SuSE release: 
SuSE Professional v9.2

* uname -a:
Linux mucltpa04 2.6.8-24-smp #1 SMP Wed Oct 6 09:16:23 UTC 2004 i686 i686
i386 GNU/Linux

* openssh
based on the following RPMs:
openssh-3.9p1-3
openssh-askpass-3.9p1-3

* let me know if you need more information

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner

--On Friday, December 23, 2005 11:07 AM +0100 Loic Domaigne 
<loic-dev at gmx.net> wrote:
> We have just found an interesting issue regarding the sshd daemon on our
> SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM
> as shown in the /proc/pid/status:
>
> $ cat /proc/`cat /var/run/sshd.init.pid`/status
> Name:   sshd
> State:  S (sleeping)
> SleepAVG:       0%
> [...]
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: 0000000000002000  <-- SIGALRM is blocked
> SigIgn: 0000000000001000
>
> As a result, any descendent processes shall inherit this mask. The bad
> news is that some commands rely on SIGALRM being unmasked, e.g. those
> invoking alarm() or similar. If those commands are started from a "ssh
> shell", then they won't work correctly (e.g. never times out).
That's
> really annoying.
If an application requires SIGALRM, it should explicitly set the signal 
handler for it. If it doesn't, it's broken.

However, looking at the openssh 3.9p1 source code, it never blocks SIGALRM. 
It uses SIGALRM to regenerate keys. So what you say makes no sense...

-- 
Carson

Loic Domaigne wrote:
> Gidday everbody, 
> 
> We have just found an interesting issue regarding the sshd daemon on our
> SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM as
> shown in the /proc/pid/status:
> 
> $ cat /proc/`cat /var/run/sshd.init.pid`/status
> Name:   sshd
> State:  S (sleeping)
> SleepAVG:       0%
> [...]
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: 0000000000002000  <-- SIGALRM is blocked
> SigIgn: 0000000000001000
you are looking at the wrong thing. You should look at the signal masks
of the descendant processes. We clear the ALRM handler in the parent
after accept().

On Mon, 26 Dec 2005, Loic Domaigne wrote:
> > Do you engage PAM in authentication? Some poorly written PAM modules
can
> > block for some reason SIGALARM while not clearing that blocking before
> starting
> > user session. If sshd itself never blocks SIGALARM, one or more of PAM
> modules
> > could be the reason of that.
> 
> Yeah, that could be the problem indeed (the thread above mention a possible
> PAM issue as well). Do you have an idea how I should proceed in order to
> find out the broken PAM module(s)?
> 
The only way I see is plugging all unknown (I mean third party modules, not the 
modules from the PAM distribution you use) PAM modules out of the corresponding 
stack and step by step plugging one by one module back in to see where the 
problem is back again. I recommend you first comparing sshd PAM configuration 
to, for example, login one (if local login sessions work fine in that respect).
Any module present in the former but missing in the latter may be the source of 
problem.
-- 

    Sincerely Your, Dan.

On December 26, 2005 5:30:49 PM +0100 Loic Domaigne <loic-dev at gmx.net>
wrote:
> Yeah, that could be the problem indeed (the thread above mention a possible
> PAM issue as well). Do you have an idea how I should proceed in order to
> find out the broken PAM module(s)?
Run sshd under gdb (or dtrace on Solaris), on entry to sigaction and
sigprocmask print the stack trace.

-frank