From: Eric W. Biederman The linux implementation of TIOCSCTTY includes an extention that provides for making a tty that is already the controlling tty of another session our controlling tty. To do this it must steal the tty away from the previous group that used it as a controlling tty. The way we are currently stealing the controlling tty away is weird. In general there is a well defined process for loosing the controlling tty. TTY hangup processing. However the linux extension that steals the tty from another process group does not invoke that. And instead just forgets the controlling tty of the processes that were part of the session. I can not imagine how our current behaviour of stealling a tty is correct or how a set of processes could deal with it reasonably. So this patch modifies the tty stealing to call tty_vhangup so we get full hanup processing when we steal a tty. I did a quick survey of user space the only application I found using this extended behaviour is sysvinit. I perform a limited amount of testing and nothing appears to have broken with this change. And I did see sysvinit pass through this piece of code. In terms of the tty leaks that started this patch series this fix should remove the last path into proc_clear_tty that has a session or a process group. Signed-off-by: Eric W. Biederman Cc: Alan Cox Signed-off-by: Andrew Morton --- drivers/char/tty_io.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff -puN drivers/char/tty_io.c~tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up drivers/char/tty_io.c --- a/drivers/char/tty_io.c~tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up +++ a/drivers/char/tty_io.c @@ -2980,9 +2980,7 @@ static int tiocsctty(struct tty_struct * /* * Steal it away */ - read_lock(&tasklist_lock); - session_clear_tty(tty->session); - read_unlock(&tasklist_lock); + tty_vhangup(tty); } else { ret = -EPERM; goto unlock; _