[Bug 245] SSH can not log out under Solaris 2.6

[bugzilla-daemon at mindrot.org]

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.