bin/183336: rsh: Blocking stdin and server

Mats Erik Andersson bsd at
Sat Oct 26 14:40:01 UTC 2013

>Number:         183336
>Category:       bin
>Synopsis:       rsh: Blocking stdin and server
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 26 14:40:00 UTC 2013
>Originator:     Mats Erik Andersson
>Release:        9.1-RELEASE
9.1-RELEASE-p7 i386
The client binary rsh(1) is reacting erroneously on SIGPIPE.
This is present since legacy time. The problem is that rsh(1)
will, except when called using the switch "-n", be using a
forked child process. When the parent process receives a
signal SIGPIPE this parent process will immediately abort,
and will never send a shutdown signal to the child process.
This situation typically arises when rsh(1) is part of a
command line pipeline, where one member fails.
The use cases

 $ rsh localhost cat /etc/motd | false

 $ rsh localhost date | true

will leave a child process still running, and will in
turn keep the server process running indefinitely and
will also steal stdin from the login session.
The problem is that the legacy code never installs
a signal handler for SIGPIPE in the function talk(),
but only later kills the client process in main().
>From the fact that the default handler for SIGPIPE is
process abortion, the whole problem arises.

Since I personally resolved this issue in a GNU project
based on BSD legacy code for rsh(1), I regretfully cannot
produce a patch for the fear of poluting you code base
away from its present license, but the above mechanism
is the culprit of this annoying issue.


More information about the freebsd-bugs mailing list