[bug-inetutils] On r-commands and iruserok.

[Mats Erik Andersson]

Dear all,

at this very moment I observe two problems in "src/" with
the available r-commands:

 1) A race condition is preventing at least GNU/kFreeBSD
    on a fast machine to end orderly from "rlogin" when
    the user issues a regular "exit" at the remote end.
    SIGCHLD is not handled timely, resulting in a need
    for additional local input of exactly two characters,
    and then SIGPIPE being involuntarily caught.

The recent commits 12aefbe and dd381d1 resolved the identical
problem on OpenBSD, but the issue persists on GNU/kFreeBSD,
and is absent with GNU/Linux on identical hardware. I have
not yet tested the situation on FreeBSD or NetBSD.

I will test whether setsigjmp(3) and longsigjmp(3) are able
to resolve the matter on GNU/kFreeBSD, since Glibc differ
between plain and sig-versions, which OpenBSD has long ago
abolished. The crucial repair was 12aefbe to "libinetutils/setsig.c",
setting correct old masks for saving.

The signal handler code in "src/rlogin.c" must still be rewritten
in due time (during next iteration), but a test is worth the effort.

 2) Both of "src/rlogind.c" and "src/rshd.c" are using iruserok(3)
    in essentially the form

      iruserok (from.sin_addr.s_addr, 0, ruser, luser)

    I am observing unexpected and consistent rejects here on
    GNU/kFreeBSD-amd64, which are only resolved when the numerical
    address is fed into "/etc/hosts.equiv", but not the corresponding
    symbolic name. The functionality is correct with GNU/Linux and
    OpenBSD. I need to double check any adaptions I might have made
    to "/etc/hosts", but otherwise the cause escapes my understanding.

Reading the manual page iruserok(3), I observe nothing that suggests

    ruserok (inet_ntoa (from.sina_addr.s_addr), 0, ruser, luser)

would function any differently from the previous call to iruserok(3).
Is this correct? Could ruserok(3) under some circumstance be compelled
to reject a host written as numerical octets? If the replacement
is usable (it only acts on numerical hosts, never on symbolic hosts),
then it would resolve my consistent issue for GNU/kFreeBSD and it
would at the same time allow us to build "rlogind" and "rshd" for
for OpenSolaris and relatives. Does the above use of ruserok(3)
still involve some security-weak step that iruserok(3) avoids? 

Best regards,
  Mats