Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!mit-eddi!smh From: smh@mit-eddi.UUCP (Steven M. Haflich) Newsgroups: net.unix-wizards Subject: Re: ioctl-ability, the TIOCCDTR problem - (nf) Message-ID: <335@mit-eddi.UUCP> Date: Tue, 28-Jun-83 08:11:07 EDT Article-I.D.: mit-eddi.335 Posted: Tue Jun 28 08:11:07 1983 Date-Received: Tue, 28-Jun-83 10:30:07 EDT References: inmet.119 Lines: 38 The notion of making IOCTL permission on a character or block device distinct from either read or write has a certain attractiveness. It could be controlled by the eXecute bits, presumably, but this screams of special-casedness! Can anyone think of a reasonable conflict with the X bits for special files? I'm not sure, but perhaps search permissions are needed for the fake files which appear "underneath" some network servers (e.g. /dev/ether/foo) ??? There are two problems being addressed by the recent discussion. If all one wants to do is permit/prohibit unauthorized read, writes, and ioctls on a tty, then present machanisms coupled with some sort of intelligent checking conventions by a setuid root talk would seem sufficient -- at least the problem is localized. However, writing a multi-user multi-terminal interactive system which remains secure is far more difficult. Such things are easy to implement under Unix if the security requirement is dropped. (Several historical multi-\ terminal games come to mind.) As each user begins execution, startup code makes his tty read/writable by everyone. However, this allows anyone *else* to manipulate the device. Even if original modes are restored upon exit, someone could have opened the device while it was lying unprotected... For most purposes, of course, such concerns are paranoid. However, if a real solution were attempted for this problem, probably it would have the form of "granting" capabilities to process groups (or whatever). In fact, an ancient PDP-1 (no typo!) operating system in the early 70's had many such interesting features for sharing and acquiring "capabilities," but I disgress. Alternatively, having the user code be setuid to a distinct group and perform the appropriate chmod's at entry and exit would seem to be sufficient. This does require support from the system manager to assign a group id and maintain the /etc/group file, but it is easy to do, requires no more rediculous warts inside Unix, and is probably fairly secure. Remember V6 when Unix was trim and lean? Steve Haflich, MIT-EMS genrad!mit-eddie!smh