Hi Damien,

> > 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 don't think it makes any sense to inherit a custom SIGALRM handler
> across exec(). That sounds like an OS bug.

I am not speaking about SIGALRM handler, I am speaking about the process
signal mask, which is something entirely different. See sigprocmask().

On UNIX, process signal mask is inherited accross fork()/exec() as specified
by the Single Unix Specification V3 standard:

The new process shall inherit at least the following attributes from the
calling process image:

* Process ID
* Process signal mask (see sigprocmask())

However, as pointed out by Dan, the problem could come from a broken PAM
module that didn't cleared SIGALRM before starting the user session. This is
more likely than a bug in sshd, IMHO.


<< Manager keeps us telling "Do not reinvent the wheel" because they want us
to reinvent the car that fits to that wheel. That's definitively more useful
than a stupid wheel. >> -- Loic Domaigne.

GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro*
Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl

openssh-unix-dev mailing list