Re: Problem with /dev/ttyp*

Theodore Ts'o (tytso@mit.edu)
Fri, 29 Sep 1995 02:47:10 -0400


From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Date: Fri, 22 Sep 1995 11:45:53 +0000 (BST)

> In any case, nowhere in POSIX is it specified that access to the tty is
> revoked (as in a hangup) to other processes after it is acquired as a
> controlling terminal by a session loeader.

Although not required, it seems to be allowed. In the Rationale under
"Implementing Job Control Systems", it mentions the vhangup() and
SysV behaviour and and confirms that conforming POSIX application's
shouldn't muck around with a controlling terminal after logout.

Yes, looking more closely, it does seem to be allowed --- not when a tty
is acquired as a controlling tty by a session leader, but upon the exit
of the session leader of the preceeding process.

After thinking about this some more, doing an implicit vhangup when the
controlling terminal exits might not be a bad idea. I can't think of
any problems this might cause. So here's a patch to do this (along with
another patch which fixes certain pty opening problems). If people
could try this out and let me know how it works, I'd appreciate it.

Please let me know if this patch causes any problems. We're making a
pretty big change in what happens at logout time, so I'd appreciate as
much testing as possible.

I know about you work on Linux, of course, which is why I'm wary about
making claims which apparently contradict your feelings. What I seem
to be claiming is that POSIX *allows* (rather than requires) an
implementation where the acquiring of a terminal as a controlling
terminal results in any other process being unable to read/write to
that terminal.

Nope, that's not what it says. It allows for the operating system to
revoke access to all other file descriptors that point to the
controlling tty of the session leader, when the session leader exits.
That's not the same as revoking all access by other processes when a
session leader acquires a tty as a controlling tty.

Again, if you can show otherwise, please send me or quote me the section
number of the POSIX standard which you think might be applicable.

- Ted

===================================================================
RCS file: kernel/RCS/exit.c,v
retrieving revision 1.1
diff -u -r1.1 kernel/exit.c
--- kernel/exit.c 1995/09/29 03:37:23 1.1
+++ kernel/exit.c 1995/09/29 06:25:38
@@ -480,8 +480,11 @@
kill_pg(p->pgrp,SIGCONT,1);
}
}
- if (current->leader)
+ if (current->leader) {
+ if (current->tty)
+ tty_vhangup(current->tty);
disassociate_ctty(1);
+ }
}

NORET_TYPE void do_exit(long code)
===================================================================
RCS file: drivers/char/RCS/pty.c,v
retrieving revision 1.1
diff -u -r1.1 drivers/char/pty.c
--- drivers/char/pty.c 1995/09/29 03:37:29 1.1
+++ drivers/char/pty.c 1995/09/29 03:39:14
@@ -77,9 +77,10 @@
return;
wake_up_interruptible(&tty->link->read_wait);
wake_up_interruptible(&tty->link->write_wait);
- if (tty->driver.subtype == PTY_TYPE_MASTER)
+ if (tty->driver.subtype == PTY_TYPE_MASTER) {
tty_hangup(tty->link);
- else {
+ set_bit(TTY_SLAVE_CLOSED, &tty->flags);
+ } else {
start_tty(tty);
set_bit(TTY_SLAVE_CLOSED, &tty->link->flags);
}
@@ -204,7 +205,8 @@
set_bit(TTY_THROTTLED, &tty->flags);
if (filp->f_flags & O_NDELAY)
return 0;
- while (!tty->link->count && !(current->signal & ~current->blocked))
+ while (test_bit(TTY_SLAVE_CLOSED, &tty->link->flags) &&
+ !(current->signal & ~current->blocked))
interruptible_sleep_on(&pty->open_wait);
if (!tty->link->count)
return -ERESTARTSYS;