TIOCCDTR (bug|feature)

[jbc at ut-ngp.UUCP]

Uh .... This ( bug | feature ) may well have been discussed before, but:
      * I've never seen it
      * others may not have seen it
      * I found it alive and kicking on three supposedly well-maintained 
        systems (2.8 w/ TCP/IP, 4.1, 4.1c) (hmmm....)

Berkeley UNIX provides a pair of line ioctl's, TIOCSDTR and TIOCCDTR, to 
set/clear the DTR bit. Fine; in fact I wanted TIOCCDTR for a hack I was
working on, but in the process of looking over that ioctl source I 
discovered no associated permission checks to speak of.

Suppose Joe Fubar is logged in on a dialup, say /dev/ttyxx with mode 622
(typical). Let's also say LNOHANG is clear (again, typical). Then suppose
the (obnoxious) user on /dev/ttyzz opens /dev/ttyxx and clears its DTR 
bit, which he *can* do ... well, the result is predictable, anyway. There's 
some debate around here as to whether this is a bug or not.

The flavor of fix is pretty obvious, but in slightly different places 
on each version. Look in d[hz].c, and, for starters, compare to
the TIOCSTI check in tty.c. What about the desirability, though? And
what about those other line ioctl's?

A colleague contends that it makes little difference, since, if your
terminal is writable, a malicious user could 'foul you up' by just 
scribbling on your terminal. Depending on what I'm doing, however, 
I see a difference between that and being logged out.  In an environment 
such as the one here, where almost all lines are on modems, I favor 
making a change.

Opinions? Comments? Thoughts on restricting other calls (e.g. other
line ioctl's)? Thoughts on making UNIX more restricted in general?
Arguments in favor of leaving things as they are (there must(?) be a 
reason for perpetuating this across releases)? But please, not 
another flame-a-thon like /dev/mem....