>> It actually occurs to me that this is a potential problem even >> today: what happens if all the processes in a session close the >> descriptors they have on the ctty, and there are no others lying >> around in other [...] > or similarly, if they TIOCNOTTY it (although tty(4) tells me it's > obsolete)
That would be testing something else. The case where a process has no ctty is comparatively well understood. I'm wondering about the case where a process has a ctty but the real ctty device is not open. > I think sys/kern/tty_tty.c is the implementation of /dev/tty, and it > seems you get ENXIO. That's what I see for open on /dev/tty if there is no ctty. (I/O on /dev/tty when there's no ctty returns EIO in the code I have at hand.) The case I'm wondering about is: - open real tty - make it the control tty - open /dev/tty - close the real tty - read/write the /dev/tty fd It looks to me as though this could lead to the underlying tty driver getting a read/write call when, according to its open/close calls, it's not open. I suspect it's a case that has never been tested; indeed, until this discussion, the possibility had never occurred to me. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B