bin/183336: rsh: Blocking stdin and server

[Mats Erik Andersson]

>Number:         183336
>Category:       bin
>Synopsis:       rsh: Blocking stdin and server
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 26 14:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Mats Erik Andersson
>Release:        9.1-RELEASE
>Organization:
>Environment:
9.1-RELEASE-p7 i386
>Description:
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.
>How-To-Repeat:
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.
>Fix:
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.


>Release-Note:
>Audit-Trail:
>Unformatted: