Unix Terminal Setup and Administration Surviving configuration tasks
From "Migration",  Access to Wang, December 1993
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Probably some of the first activities you will perform as a Unix system administrator is to set up a new terminal or modem. Like aspects of the file and security systems previously covered, Unix operational control functions have a terse, uninformative style and are typically used from a command prompt. As always, there is great power in Unix operator functions but access to them is primitive.

VS systems administrators will be disappointed with the appearance and accessibility of task and workstation control functions shipped with Unix operating systems; the familiar screen-oriented utilities that assist in the setup process will be sorely missed. It is possible to survive such configuration tasks, though. Here is a guided tour for administrators or programmers.

Again, a warning: Many of the administrative functions described below require access to root privileges (a.k.a. the superuser or wheel). It is very important to use such an ID carefully, since it is easy to make an error that endangers your system. It is never advisable to use the root logon for routine work, nor to leave a terminal unattended when root is logged on. Stay sharp!

Configuring ports

Unix offers many types of peripheral connections, so the manner in which you control them varies accordingly; for this purpose we will assume you are using serial terminals and printers connected to the Unix host. The system knows about each device from files in the /dev directory - at least one file for each configured port. The file name gives the type of peripheral and its logical location on the system's controllers. This relationship of physical port to logical identifier is similar in theory to that of the VS configuration tool, GENEDIT, but there is no flexibility in the assignment of the port identifier; each port number reflects its physical location on the controller. The files in this case are actually routes to and from the device itself, since Unix processes treat almost all resources as if they were files.

The type of device connected to a port is not known to the system; instead, the general usage for the port is specified in the /etc/inittab file (System V Unix) or /etc/gettytab (Berkeley Unix). These tables specify the speed and general usage of a device. For example, a terminal or modem port must be set to generate a login prompt whenever the line is activated, while a printer cannot use such a prompt. Similarly, terminals that are directly connected to the system have no need for outbound communication, while modems may be used in either inbound or outbound directions.

Setting up terminals

Once a port is activated properly it can be used by a variety of terminals. Specific terminal type information is kept in the /etc/termcap or /etc/terminfo files. These files list terminal models and their characteristics, including the speed, type of connection (local, remote), whether the line must be hung up after use (e.g. for modems), and information on specific keys. It is possible to write entries for these files but it is far more common to fit your device types into the definitions supplied by the manufacturer - definitions that typically include many variations of Digital Equipment VT-series terminals, ANSI terminals, simple teletypes, X-window terminals and workstations, and other devices. (Terminal keyboard codes and their use are a surprisingly important topic that will be covered later; suffice to say that the meanings of function keys, backspace, and cursor control keys is far from universal.)

The exact type of terminal is controlled by the user at logon time. Most often this value is set by a tset command in the user's .profile file, functionally associating a terminal type with a user ID - not always a predictable relationship. Shell variables (TERM on System V systems) carry the value of the user's terminal type for programs to check, and most common Unix utilities adjust their behavior according to the type of terminal. If a user works from several types of workstations it is possible to prompt for the type during the startup process. Typical terminal types include VT102, VT220, ADDS, HP, IBM 3151, ANSI (similar to a VT100), and XTERM (an X-windows terminal).

Naturally, terminals must also be physically connected to the system. Serial terminals typically require a RS-232 connection that uses from three to seven wires. Short-haul modems and other communications gear can be used to reduce the number of signals required for a connection, extend the effective range, and allow conventional telephone wire to be used for the connection rather than data-grade shielded wire. Again, these are subjects that must be examined in more depth at another time.

Monitoring terminal activities

Once the port's characteristics are identified to the system, a Unix task called a getty (get TTY) is generated to monitor the port's activities and act as a liaison to the system. Like the device files, getty processes exist for all serial connections that have been defined. The Unix process control command ps lists these getty processes in addition to all user processes. To list all processes on a system, enter ps -ef (System V) or ps -aux (Berkeley). In either case, be prepared for a long list, since every process currently running will be shown. One way of handling this list is to pipe the output to the more utility so that individual pages can be viewed. Try ps -ef | more to see how this works.

Since it is difficult to find a single user's task in the midst of such a long listing most administrators filter out tasks that do not contain specific text, such as the user ID. The Unix grep utility - a search tool - can be easily used for this purpose. To search for the processes associated with user dsb, for example, enter ps -ef | grep dsb. The result will be just the process lines that contain the text "dsb" - including the ps statement itself.

When a port is idle, the getty process is running to check for a login. Once the login process in complete, the getty process "dies" and is replaced by the first user process, typically a shell. Like all processes, a unique process ID is assigned to this task. As the user runs more processes each are shown as child processes to this first task; that is, their parent process ID shows that they are associated with the first task. When a parent process dies, the associated child processes are supposed to die as well; this relationship is similar to link levels in the VS operating system. Thus, to kill a user's tasks completely the administrator must find and kill each related process, preferably in the reverse order of their creation.

It should be clear that administering a complex system Unix system without the benefit of some tools is difficult at best. Some vendors provide such tools, but more often it is the responsibility of the system administrator to create scripts for their own routine use or buy tools from others. Such tools are the fodder of many Unix books currently in print, and will be shared in this column as well.

The superuser: why so dangerous?

Since my first contact with Unix, I have been struggling with the differences between root privileges on Unix systems and System Security Administrator status on VS systems. Both have access to almost all information on the system, but root privileges are more dangerous. Consider these points:

Wang system processes (the Sharer, the file manager, etc.) are launched during an IPL and cannot be stopped through normal means. Almost all Unix tasks can be stopped by a persistent root user.

Unix terminal I/O is crude, allowing input and output from a terminal to be monitored by another terminal. It is possible for a sophisticated user to monitor the activities of those using root privileges and record the commands they type, including those that contain passwords and other sensitive information.

The terse style of Unix commands makes it easy to perform activities that damage the system without seeing the results. Example: it is possible to remove all files along a given branch of the file system with a single command and without any acknowledgment of the results.

Many Unix configuration files contain text information in cryptic formats, making mistakes easy. Their contents are read into memory by the system and the files closed, allowing them to be modified or deleted while in use. VS system files are typically open while in use and cannot be scratched.

The Unix operating system itself is written in a high-level language (C) and its internal structure is relatively well understood by users worldwide, making it easier to exploit security weaknesses.

In spite of these obstacles, I believe the security features of Unix make it possible to secure a system as well as any other operating system. Please send me any questions or comments you have regarding Unix security and I will attempt to answer them here.

Unix Bookshelf

Unix Power Tools
Jerry Peek, Tim O'Reilly, Mike Loukides and others
O'Reilly & Associates/Bantam Books, Sebastopol, CA and New York, NY; 1993
ISBN 0-553-35402-7

Large, impressive collection of Unix tips and utilities from many sources. Primarily scripts for system administration, directory movement, disk space management, and personal productivity. Includes CD-ROM of items mentioned in book.