[Bug 2071] sshd closes stderr but not stdout when child process exits

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Thu May 12 01:02:52 AEST 2016


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

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #13 from Jakub Jelen <jjelen at redhat.com> ---
Yes, the issue is certainly related to the bug #52, but I don't think
it is caused by the workaround for this bug. The patch for the above
mentioned bug modifies handling of output and error streams, but each
of them different way. The stdout is blocked without TTY but the stderr
is not.

I spent some time with this case and finally ended up with the patch
below. 
I was unable to reproduce the problems from the previous bug nor from
this one. Yes, it is basically the same hack for the seconds stream,
but probably better than noting and running into another weird and
unexpected SIGPIPE exits.

Also running regress tests passed for me just fine with 6.6p1 version,
but this part didn't see many changes since then so git head should be
good too (still running some tests).

diff --git a/channels.c b/channels.c
index 7ee1f98..2601ad5 100644
--- a/channels.c
+++ b/channels.c
@@ -1835,7 +1835,7 @@ channel_handle_efd(Channel *c, fd_set *readset,
fd_set *writeset)
                        debug2("channel %d: read %d from efd %d",
                            c->self, len, c->efd);
                        if (len < 0 && (errno == EINTR || ((errno ==
EAGAIN ||
-                           errno == EWOULDBLOCK) &&
!c->detach_close)))
+                           errno == EWOULDBLOCK) && !(c->isatty &&
c->detach_close))))
                                return 1;
                        if (len <= 0) {
                                debug2("channel %d: closing read-efd
%d",

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list