sshd blocks SIGALRM
dan at D00M.lightwave.net.ru
Sat Dec 24 23:15:42 EST 2005
On Fri, 23 Dec 2005, Loic Domaigne 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
> > 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().
> Perhaps I wasn't clear enough. We execute a command in a (remote) bash shell
> started by the sshd. This command never timed out, because alarm() didn't
> worked as it should.
> After some non trivial investigations, we found out that SIGALRM was blocked
> in the signal set of the remote shell we were using, and hence in our
> command since the signal mask is inherited accross fork()/exec().
> I traced back the process hierarchy going from child to parent to find out
> who did block SIGALRM in first place, and I found: /usr/sbin/sshd. Note that
> the same command works fine in a "local" shell (that is a shell that is not
> started by sshd).
> This is the same problem than the one discussed in the following
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.
Sincerely Your, Dan.
More information about the openssh-unix-dev