[PATCH 4/4] tty: In tiocsctty when we steal a tty hang it up.

[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 <ebiederm@xxxxxxxxxxxx>
---
 drivers/char/tty_io.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index 0843fcb..0f5a781 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -2982,9 +2982,7 @@ static int tiocsctty(struct tty_struct *tty, int arg)
 			/*
 			 * Steal it away
 			 */
-			read_lock(&tasklist_lock);
-			session_clear_tty(tty->session);
-			read_unlock(&tasklist_lock);
+			tty_vhangup(tty);
 		} else {
 			ret = -EPERM;
 			goto unlock;
-- 
1.5.0.g53756

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/