the other bsd tty problem

[Keith Muller]

There are two different problems with ttys being discussed wrt Dan. Not all
the problems can be traced back to poor implementations of the controlling
tty device. For a moment stop thinking of ways that exploit THAT bug and have
an open mind. This all started when I pointed out that blocking access to a
a tty because there is a valid reference to it is an overkill in solving
a specific type of problem.  To quote from that first posting: 

"In simple terms a major problem with ttys has always been the semantics
of the revocation of access rights to a tty (pseudo or real). The difficulty
is created by both "valid" processes and "revoked" processes sharing access
to common data structures (inode and device tty structures) and the
routines which implement tty semantics."

The problem being addressed here are sleeping processes which still
retain access rights when they are down in the tty routines. They do
NOT HAVE TO OPEN THE CONTROLLING TTY to get these rights. Log onto two ports
open a few file descriptors, stop a few processes, log off a tty... and
you get the idea (the setting of the controlling tty is not an
issue here, processes BLOCKED before completing the operation and after the
access checks are made IS THE PROBLEM).  The result is that
sleepers when they resume execution get to complete the operation they
were blocked on regardless of any change done in access to the actual
device while they were sleeping.  Processes (including the bad guy) can
directly reference the same device (going indirectly through the controlling
tty device is not needed).

In several postings I have described two methods directed at THIS problem:
a vhangup() based approach for machines that use that and a generation
based approach which is what is used in 4.3 reno and later to address THIS
problem.

Several vendors have (or are) addressed the controlling tty bug by sessions
access (such as revoking session access to the controlling tty as done by one
vendor). However the vendor techniques we have seen here (so far) for fixing
controlling ttys have not yet solved the sleeper issue. So it still needs to
be considered, which is why I brought it up. (as dan points out the machines
I use have fixed much of the controlling tty bug, but we did have to
address those sleepers).  Yes dan's solution avoids the sleepers problem
by never using that tty until the sleepers go away (which may be never).
I would rather use a direct approach which allows tty reuse (FOR THIS PROBLEM).

------- flame on ----

I didn't say "all" problems, but "a" major problem (note the singular).
I didn't say "do this and all you tty problems are solved". "I didn't say
don't run Dans package as this is all you have to do".  I did say here is a
problem with "sharing common data structures (inode and device)" that can
be simply solved DIRECTLY (to allow reuse of the device for a specific shared
access problem) without the potential for blocking access to the device forever.
I do feel that dans method requires way too complexity in the user process,
and the kernel should be doing that. But that is an opinion. I also do not
want to force hardware ports through ptys in order to use them (a poor 1 mip
box can handle 32 hardwired ports but add 32 active ptys and you have one
slow machine).

Dan complained I was too vague for him to implement a fix. It is a fine line
between giving out information without creating complaints about posting
code on how to attack some phase of the system. The vendors I talked to
knew exactly what was going on and went off to fix it. I had hoped that
describing a technique with words like "sleepers resume execution.."
would be enough. I do worry that I may have said too much in this posting.
I really suspect that this is an old problem, but when it kept cropping up
even after the controlling tty bug was being addressed it wasn't clear what
was happening.

When Dan went on about ttys operation not going through the open file
table and checks "are not done". I did not immediately equate this to the
controlling tty bug. I focused on the "does not go through the open file
table" statement which is technically misleading (when looking at the path 
a system call makes on a fd at entry to the kernel the open file table
(in the source we have here) is always gone through. I suspect dan
was referring to later jumps into the tty by the controlling tty device after
testing the access to the controlling tty device). Yes I looked at too
much source and got the names of the variables used for the
controlling terminal confused but until I realized we were talking
apples and oranges, the significance wasn't there. For this slowness I do 
apologize to the net.

In retrospect had the statement been a bit more direct like: "that this fails
to handle the case where f_data does not point at the tty inode but points
at the the controlling tty device inode which makes your technique miss
clearing f_flags.....", I would have seen we were talking about different
(but very similar in effect) bugs. My error.  Of course when much of a
persons objection consists of "ad hominem" attacks, listening does becomes
difficult :-). Oh well.

In the interest of stopping this (instead of posting rebuttals to all of
Dans attacks etc; it has already gotten blown way out proportion),
lets take further comments and attacks on this topic offline to e-mail.

Keith Muller
University Of California