[Bug 2863] New: sshd with ControlMaster does not close child STDERR on client exit

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2863

            Bug ID: 2863
           Summary: sshd with ControlMaster does not close child STDERR on
                    client exit
           Product: Portable OpenSSH
           Version: 6.6p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: nelhage at nelhage.com

If I'm using ControlMaster, after the `ssh` client goes away, the
`sshd` closes the STDOUT and STDIN pipes for the child, but not STDERR.
If the child is writing to STDERR, this can result in it hanging and
being effectively orphaned until `sshd` terminates.

How to reproduce:

# In one terminal, start the ControlMaster
ssh -oControlMaster=yes -oControlPath=$HOME/example.sock example.com

# In another terminal, start a process using that ControlPath that
writes to STDERR:
ssh -oControlMaster=no -oControlPath=$HOME/example.sock example.com
'echo i am pid $$; exec yes >&2' 2> /dev/null
i am pid 8176
# Hit ^C to disconnect the client
# Now, back on the server, observe that 8088 is still running:
$ ps -f 8176
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
nelhage   8176  7802  0 16:37 ?        Ss     0:00 yes

# And is blocked on STDERR:

$ strace -p 8176
strace: Process 8176 attached
write(1, "y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"..., 8192


# If we look at its fd's, and at sshd's fds:

$ ls -l /proc/8176/fd/
total 0
lr-x------ 1 nelhage nelhage 64 May  1 16:37 0 -> pipe:[26685784]
l-wx------ 1 nelhage nelhage 64 May  1 16:37 1 -> pipe:[26685786]
l-wx------ 1 nelhage nelhage 64 May  1 16:37 2 -> pipe:[26685786]
$ sudo ls -l /proc/7802/fd/
total 0
lrwx------ 1 root root 64 May  1 16:39 0 -> /dev/null
lrwx------ 1 root root 64 May  1 16:39 1 -> /dev/null
lrwx------ 1 root root 64 May  1 16:39 11 -> /dev/ptmx
lrwx------ 1 root root 64 May  1 16:39 12 -> /dev/ptmx
lr-x------ 1 root root 64 May  1 16:39 16 -> pipe:[26685500]
lr-x------ 1 root root 64 May  1 16:39 17 -> pipe:[26685511]
lr-x------ 1 root root 64 May  1 16:39 18 -> pipe:[26685786]
lrwx------ 1 root root 64 May  1 16:39 2 -> /dev/null
lrwx------ 1 root root 64 May  1 16:39 3 -> socket:[26680195]
lrwx------ 1 root root 64 May  1 16:39 4 -> socket:[26684902]
lrwx------ 1 root root 64 May  1 16:39 5 -> socket:[26684932]
lr-x------ 1 root root 64 May  1 16:39 6 -> pipe:[26680934]
l-wx------ 1 root root 64 May  1 16:39 7 ->
/run/systemd/sessions/8548.ref
l-wx------ 1 root root 64 May  1 16:39 8 -> pipe:[26680934]
lrwx------ 1 root root 64 May  1 16:39 9 -> /dev/ptmx

# We can see that STDERR (pipe:[26685786]) is still open in the ssh
daemon, but STDOUT and STDIN (…84 and …85) were closed.
#
# The lingering `yes` process is now hung and stuck until the original
ssh session finally exits.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.