bugzilla-daemon at mindrot.org
2002-Dec-13 13:36 UTC
[Bug 245] SSH can not log out under Solaris 2.6
http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From dtucker at zip.com.au 2002-12-14 00:36 ------- Did some digging on this. Carson seems to be correct in that the problem is due to missing controlling terminal. I uncommented the setsid() in sshd.c and added some debugging log() calls to sshd, which generated the following: sshd[21690]: main: before setsid sid=21460 sshd[21690]: main: after setsid sid=21690 sshd[21690]: Accepted publickey for dtucker from 192.168.1.1 port 1665 ssh2 sshd[21694]: pty_make_controlling_tty called, ttyfd=7, cttyname=/dev/pts/2 sshd[21694]: pty_make_controlling_tty: file descriptor 7 is tty /dev/pts/2 sshd[21694]: pty_make_controlling_tty: before setsid, ppid=21690, sid=21690 sshd[21694]: pty_make_controlling_tty: after setsid, ppid=21690, sid=21694 sshd[21694]: error: open /dev/tty failed - could not set controlling tty: No such device or address # ps -l -p 21690,21694 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD c8 S 500 21694 21690 1 44 20 f62bd7a0 618 f66d18fe ? 0:00 bash c8 S 0 21690 21460 1 46 20 f65c17c0 650 f66a6d92 pts/2 0:01 sshd Note that sshd has picked up a controlling terminal. # ps -j -p 21690,21694 PID PGID SID TTY TIME CMD 21694 21694 21694 ? 0:00 bash 21690 21690 21690 pts/2 0:01 sshd So what seems to be happening is: 1) sshd daemon forks process to handle connection 2) sshd child calls setsid and becomes session leader 3) child allocates pty, and aquires new pty as controlling terminal 4) child forks again, calls setsid and attempts to make pty controlling terminal. This fails because the pty is already controlling terminal for another session. Looking at a truss -f of sshd for access to that pty shows: # grep /dev/pt /tmp/sshd.trace |grep 21690 21690: open64("/dev/ptmx", O_RDWR|O_NOCTTY) = 6 21690: access("/dev/pts/2", 0) = 0 21690: open64("/dev/pts/2", O_RDWR|O_NOCTTY) = 7 21690: stat64("/dev/pts/2", 0xEFFFF020) = 0 21690: chown("/dev/pts/2", 500, 7) = 0 My guess is that one of the accesses without the O_NOCTTY flag accidently picks up the newly allocated pty as the controlling terminal. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2002-Dec-13 14:26 UTC
[Bug 245] SSH can not log out under Solaris 2.6
http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From dtucker at zip.com.au 2002-12-14 01:26 ------- Update: splitting out the pty ops into a test program shows that pushing the STREAMS modules is what causes the controlling terminal to be acquired, ie sshpty.c:132 if (ioctl(*ttyfd, I_PUSH, "ptem") < 0) error("ioctl I_PUSH ptem: %.100s", strerror(errno)); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2002-Dec-13 23:21 UTC
[Bug 245] SSH can not log out under Solaris 2.6
http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From dtucker at zip.com.au 2002-12-14 10:21 -------
bugzilla-daemon at mindrot.org
2002-Dec-14 03:24 UTC
[Bug 245] SSH can not log out under Solaris 2.6
http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From dtucker at zip.com.au 2002-12-14 14:24 ------- The root cause appears to be an 8-year-old bug in Solaris (Sun bugid 1156877). The bug is marked "fixed" but the testcase fails on my Solaris 8 box (with recommended patches from a few weeks ago). [quote] The open routine of the master-side pty driver (ptm) sends an M_SETOPTS message to the stream head that, among other things, has the SO_ISTTY bit set. This action has the effect of expressing willingness to act as a controlling tty. However, it is nonsensical for the driver to do so, since it supports none of the other tty semantics. [snip] However, opening /dev/ptmx with O_NOCTTY only prevents the problem until the user pushes another module on the stream head. Note that this only happens if the process has no controlling terminal already. [snip] Work Around Open the master-side pty with the O_NOCTTY open flag. This works only if you don't push any streams modules - a rather special case. [/quote] ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2002-Dec-14 04:08 UTC
[Bug 245] SSH can not log out under Solaris 2.6
http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From carson at taltos.org 2002-12-14 15:08 ------- A rather obnoxious work-around would be to close the tty in the parent (thus removing it as the controlling terminal for that process). Unfortunately, the child would have to be told somehow that the parent is done closing the tty, and that is annoying to do well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2002-Dec-14 05:22 UTC
[Bug 245] SSH can not log out under Solaris 2.6
http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From dtucker at zip.com.au 2002-12-14 16:22 ------- Created an attachment (id=187) --> (http://bugzilla.mindrot.org/attachment.cgi?id=187&action=view) Don't call setsid() on Solaris only ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
Maybe Matching Threads
- openssh-1.2pre16 patch to pty.c for Solaris 2.6
- [PATCH] isatty(): use TCGETS instead of TIOCGPGRP, like dietlibc does
- [PATCH] isatty(): use TCGETS instead of TIOCGPGRP, like dietlibc does
- [PATCH] isatty(): use TCGETS instead of TIOCGPGRP, like dietlibc does
- Porting to Dynix 4.1.3...