The ``Session Tty'' Manager S.M. Bellovin ulysses!smb AT&T Bell Laboratories Murray Hill, NJ 07974 ABSTRACT In many UNIXÒ systems, it is possible for a program to retain access to the login terminal after the user has logged out. This poses obvious security risks and can also confuse the modem control signals. We solve this for System V by adding a layer of indirection known as the session tty driver. At login time, a session device is linked to the physical terminal. User programs have access to the session device only, and may not open the physical line. Upon logout or carrier drop, the link is severed. New login sessions are given new session devices, and are thus insulated from persistent processes. Use of session devices is controlled by a new system process known as the session manager; by means of suitable plumbing primitives, a ``reconnect after line drop'' facility can easily be implemented. 1. INTRODUCTION ``Any software problem can be solved by adding another layer of indirection.'' When a user logs on to a UNIXÒ system, a shell is ®red up with ®le descriptors 0, 1, and 2 connected to the physical tty device used. All commands executed by that user are descendants of the shell, and normally use the same tty device for input and output. These associations Ð so fundamental to the design of the system Ð cause trouble under certain circumstances. These problems may be solved by adding a level of indirection called the ``session manager''. Before we discuss the solution, it is, of course, helpful to know what problems it claims to cure. There are several, mostly having to do with ending conditions: 1. When the physical device receives an external close indication Ð i.e., when carrier has dropped, the user's terminal has been turned off or disconnected, or a network close request is received Ð this fact must be propagated to all processes using that terminal. It is not suf®cient to send SIGHUP. Some processes may have the signal ignored; others may not have the device as their controlling tty, and hence will not receive the signal at all. In either case, the result is the same: the next user of the line can receive some strange and wondrous garbage. 2. When the login shell Ð the process group leader Ð exits, the ``session'' (whatever that is) should end. Access rights to the terminal by any child processes should be revoked, regardless of whether the physical connection has been broken. If we are dealing with a network connection, such a disassociation may be needed to complete the protocol close processing. The system currently attempts to deal with this by sending SIGHUP when a process group leader ends; as noted, this is often insuf®cient. 3. When the host signals external equipment (i.e., modems) that a terminal session has ended, typically by dropping DTR, it must then immediately spawn a new getty process, and re-enable DTR. Failure to do either causes trouble: some other process may try to read from the line instead of getty1, or the line may appear to be dead, thus blocking a telephone ``hunt group''. - 1 - Historically, these requirements have been a very fruitful source of bugs. Most versions of the UNIX system either suffer from such bugs, contain large amounts of code to try to avoid them (i.e., forceclose() in the 9th Edition and 4.nBSD kernels), or both. None of these solutions is particularly satisfactory. The session tty mechanism avoids all of these problems by decoupling the physical tty device from the tty device visible to the user. A logical connection is established at login time; it is severed when either the physical device notices that the connection has dropped, or when the login shell exits. In addition to solving the original problem, there are several other bene®ts to session ttys: 1. Permitting a user to reconnect to a session after a physical hangup is easy. 2. Remote login sessions can be assigned ``tty'' names for /etc/utmp entries; thus, they will show up via who. 3. The /etc/utmp entry for the login session will remain around while any child processes persist. This helps system administrators track down hidden resource consumers. 4. Resources allocated to a session Ð say, a tape drive assigned to a user for the duration of several commands Ð should be revoked when the session ends. In current systems, it is very hard to determine when this is true. 5. Certain stream modules whose usage must be beyond the user's control (i.e, encryption or audit modules) can be protected from tampering. 6. Non-login sessions Ð circuit-based network connections, cron jobs, etc. Ð can have utmp entries as well. 7. Depending on certain design questions that are not yet clear, session ttys may provide a clean solution to the problem of which window is logged in when using layers. 8. Again, depending on certain as-yet unresolved questions, use of tty lines for two-way traf®c may become signi®cantly cleaner and easier. The implementation discussed here is for System V Release 3, as it heavily relies on streams[1] and on several other unique features, such as multiplexor devices and clone devices.2 Some features not in the standard system, such as a streams-based terminal line discipline, are also used. It is possible to implement the session manager on other versions of the UNIX system, but it is somewhat more dif®cult to do so. 2. HOW IT'S DONE There are three key components to the new design: the session manager, a multiplexed device driver known as sesstty, and one or more line managers. Depending on the exact hardware and software con®guration, the line manager may be a separate process, part of an existing ``listener'' process, or part of the session manager itself. 2.1 The Current Structure Before we discuss the new implementation, let us review the current login management structure. When the system makes a transition to multi-user state, /etc/init creates a child process for each tty line, as de®ned in /etc/inittab; each child process in turn executes /etc/getty, which opens the actual device. When the open succeeds, getty sets up the hardware environment (principally the line speed), collects the user's login id, and passes control to /bin/login. As noted earlier, the physical device __________________ 1. The security implications of this are amusing; it allows a process to imitate getty and login, thus capturing users' passwords. 2. See the glossary at the end. - 2 - opened by getty is passed directly to login. Login validates the login id (i.e., veri®es a password), creates an entry in /etc/utmp3, sets up the user's environment, and passes control to the user's shell. The only fork() operation in the entire process is the one performed by init; the user's shell is thus a direct descendant of init, with a process id known to init. We refer to that process as a session process. When the shell terminates Ð that is, when the user logs off Ð init is noti®ed of the process id; it cleans up the utmp entry and spawns another getty process for that line. The following table summarizes the process: TABLE 1. Division of Responsibility ____________________________________________________________________ ____________________________________________________________________Program Function External triggers /etc/init Fork and invoke getty Previous session process died ____________________________________________________________________ Clean up /etc/utmp entry /etc/getty Hardware environment setup Line open succeeds ____________________________________________________________________ Collect login id /bin/login Validate login id Software environment setup ____________________________________________________________________ Create /etc/utmp entry /bin/sh (user session) ____________________________________________________________________ exit User logs off or line drops Network tty connections do not differ in any fundamental way. /etc/init is no longer in the picture; the login shell will be child of some network listener process. It in turn is responsible for cleaning up any utmp entries. Getty may or may not be used. 2.2 A Brave New World The primary conceptual change in the new system is that the physical device is no longer passed directly to login. Rather, a software pseudo-device Ð sesstty, as you probably guessed Ð is opened by getty. By dint of the clone device driver, a separate sesstty device is used for each session. Next, the physical line is spliced to the sesstty device by the I_LINK ioctl() call. For the duration of this session, all references to the line, including its /etc/utmp entry, are via the sesstty device instead. The following diagram summarizes the situation: __________________ 3. Strictly speaking, the /etc/utmp entry is created by init. This is primarily a bookkeeping entry, however; the signi®cant entry Ð i.e., the one showing that someone has logged in Ð is created by login. - 3 - user command user shell /dev/sess07 /dev/tty03 When the physical line drops, the connection between the session device and the physical device is broken. As shown below, a new invocation of getty can attempt to reopen the line, without affecting the old session device still being used. user command user /etc/getty shell /dev/sess07 /dev/tty03 The connection is also severed if the shell exits while any of its children are still running: - 4 - user command . /etc/getty . /dev/sess07 /dev/tty03 Although the new scheme appears to be a minor enhancement to the current system, there are actually several complicating factors. For one thing, we have added some new external events. A new getty process must be spawned when the link is severed; this may or may not be coincident with the demise of the session process.