Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!seismo!hao!cires!nbires!ut-ngp!jbc From: jbc@ut-ngp.UUCP Newsgroups: net.unix-wizards,net.bugs.4bsd Subject: TIOCCDTR (bug|feature) Message-ID: <349@ut-ngp.UUCP> Date: Thu, 16-Jun-83 02:44:37 EDT Article-I.D.: ut-ngp.349 Posted: Thu Jun 16 02:44:37 1983 Date-Received: Thu, 16-Jun-83 22:44:38 EDT Lines: 34 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....