[Bug 271] New: SSHD should unblock SIGCHLD - POSIX signal blocks survive exec()
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Wed Jun 12 00:43:13 EST 2002
http://bugzilla.mindrot.org/show_bug.cgi?id=271
Summary: SSHD should unblock SIGCHLD - POSIX signal blocks
survive exec()
Product: Portable OpenSSH
Version: -current
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P2
Component: sshd
AssignedTo: openssh-unix-dev at mindrot.org
ReportedBy: Nicolas.Williams at ubsw.com
POSIX requires that signal block masks be inherited across exec() calls.
As a result, any porgram that needs to use specific signal and which has no
good reason to accept inheritance of blocking of such signals should explicitly
unblock those signals.
Furthermore, login-type programs should really unblock all signals, IMO (I have
yet to find a scenario where I'd want my login shell to inherit and keep any
non-empty signal mask).
If sshd is started with SIGCHLD (SIGCLD) blocked then sshd ends up failing to
notice the death of child processes, and therefore SSHv2 sessions hang on exit.
Diagnosis is trivial on any OS that provides tools for inspecting the signal
disposition of a process: if an sshd has at least one defunct process, sleeps
in poll()/select() and has SIGCHLD blocked, and its SSHv2 client is hanging on
exit, then the sshd must have been started with SIGCHLD blocked. Out of
thousands of installations I have witnessed this behaviour on three systems.
At the very least sshd should, early on, use sigprocmask() to retrieve the
current mask, clear SIGCHLD from the mask and set the modified mask.
Preferably, perhaps, sshd should set an empty signal mask before exec()ing any
program on behalf of a client.
Most shells (I've checked a few, including Bash) clear SIGCHLD from the signal
mask, but generally don't clear all other signals from the mask.
NOTE: sigprocmask() can have its new signal mask pointer argument given as
NULL, in which case sigprocmask() should only retrieve the current mask and
ignore its first argument, but the compatibility shim provided by portable
OpenSSH does not support this mode of operation. This can be fixed with a one-
liner.
NOTE: This issue is relevant to all POSIX-compatible platforms.
Thoughts?
Nico
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the openssh-unix-dev
mailing list