Mailing List Archive

OpenSSH, unreliable signals, SA_RESTART and sigaction
Hi all.

If you don't use OpenSSH on a system:
- with unreliable signals (maybe UNICOS?)
- that might not like SA_RESTART (maybe HP-UX?)
- that does not have sigaction() (maybe nothing?)
then you can stop reading now.

*** Unreliable signals

The original ssh1 code on which OpenSSH is based assumed original Unix
unreliable signals and reinstalled its handler on each signal, so the
signal handlers are littered with calls to signal(). Well, actually,
only the older ones are, the ones added in the last decade or so don't
which leads me to believe that nobody is running modern OpenSSH on a
system without reliable signals.

There's also this gem in serverloop.c, which makes me suspect that
UNICOS is the last such system that worked:
sigchld_handler(int sig) {
int save_errno = errno;
child_terminated = 1;
#ifndef _UNICOS
mysignal(SIGCHLD, sigchld_handler);
#endif

I am removing the code that re-installs the signal handlers, which
will break any platforms that have only unreliable signals, however as
detailed above I suspect that these have been broken for a long, long
time. I do have a plan that could make it work, but I don't want to
do that unless it's needed

If you care about such systems please tell me.

*** SA_RESTART

OpenSSH currently uses a wrapper function ("mysignal") around that
implements mostly BSD signal semantics. It'll used native sigaction()
if available or native signal() via the fallthrough. There is also an
implementation of sigaction built on top of sigvec
(opensbd-compat/sigact.c) however as far as I can tell it can never be
used; mysignal falls through to signal() if HAVE_SIGACTION is not set
and the compat code in sigact.h doesn't set it.

The missing piece of BSD semantics is SA_RESTART, which I'd like to
fix. This was attempted once before a long time ago [0] but was
rolled back due to problems with HP-UX[1]. After some research [2] I
believe this is because it restarts select() after a SIGCHLD[3],
preventing sshd from exiting its event loop.

Please let me know if you have access to such systems to test.

*** sigaction

Once these are sorted out I will be looking at replacing all signal()
calls with sigaction because the semantics of the latter are
unambiguous. Everything for which we have survey data has it (plug:
please run "make send-survey" especially if you have an unusual
platform! we actually use the data to make decisions).

If you care about a platform that doesn't have sigaction please let me know.

Thanks.

[0] https://marc.info/?l=openssh-unix-dev&m=98245857803197&w=2
[1] https://lists.mindrot.org/pipermail/openssh-unix-dev/2001-June/007125.html
[2] https://www.dtucker.net/openssh/sa_restart.mbox.txt
[3] https://lists.mindrot.org/pipermail/openssh-unix-dev/2001-June/007111.html

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH, unreliable signals, SA_RESTART and sigaction [ In reply to ]
Hi folks.

On Mon, 12 Feb 2018 at 19:10, Darren Tucker <dtucker@dtucker.net> wrote:

> [...]
> *** SA_RESTART
>
> OpenSSH currently uses a wrapper function ("mysignal") around that
> implements mostly BSD signal semantics.
>

I have just committed code to put SA_RESTART back into the mysignal wrapper
making it, as far as I can tell, fully implement BSD reliable signal
semantics. This was know to cause problems in the past, so committing this
early in the release cycle gives the maximum chance to shake out problems
before the next release.

If you still use systems suspected of having problems with this in the past
(based on the list archives, that's likely to be HP-UX 10 or UnixWare 2)
please test this before the next release. If we do discover any currently
in use platforms that have problems with this we'll look at disabling it
just for those platforms.

Thanks.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev