Granting access to the terminal in Plash
Granting a process access to a terminal (tty) has issues similar to those associated with the X Window System (see X11Security), although terminals under Unix are a lot older.
- A process with access to the terminal can send input to other programs, pretending to be the user.
- The process can pretend to be other applications (spoofing), and trick the user into giving it passwords.
Background
There are two components associated with a terminal:
- The tty device, which under Linux is implemented by the kernel.
- The terminal itself, implemented in user space, e.g. xterm.
Kernel tty device
The kernel tty device is a layer between applications and the actual terminal. It provides some translation and buffering of the byte stream between the two. These translations can be switched off. In addition to being a byte stream interface, its state can be read and modified using ioctl() calls.
The tty device can be switched between various modes (raw, rare, cooked). It can provide a simple line editing facility. It implements echoing of characters to the screen. It can add carriage returns after newline characters.
It is connected to the job control system, so characters entered at the terminal cause signals to be sent to processes. e.g. Ctrl-C interrupts processes, Ctrl-Z suspends processes. Processes can be associated with a controlling tty device.
Terminal
The terminal is implemented in user space, and there are many to choose from: xterm, gnome-terminal, rxvt, etc. Historically, it was a physical device, connected via a serial cable. Either way, its interface is a bidirectional stream of bytes. There are no ioctl()s involved.
The terminal almost always interprets ANSI escape codes (which start with ESC, char 27); see http://vt100.net.
Questions
How does Plan 9 handle terminals? It probably uses byte streams without providing ioctl().