Cover V02, I05
Figure 1


Questions and Answers

Bjorn Satdeva

USENIX Loses a Friend

Jim Joyce, a well-known USENIX personality, died quietly in his sleep just before Memorial Day weekend, after a long illness. In recent years, Jim has probably been best-known for the traveling bookshop be brought to many USENIX conferences (possibly starting the influx of bookstores and publishers to the various USENIX conferences and workshops). I believe that Jim was also involved in some of the early development of BSD UNIX, though, he talked little about this, except when referring to old friends from that period.

LISA Conference in Europe and USA

The European LISA conference, arranged by UKUUG LISA, has been rescheduled and will take place in London, 9 September, this year. The theme of this year's System Administration and Management conference is "Coping with Change -- Strategies for Hitting a Moving Target." Besides the technical track, this conference will see the creation of SAGE/UK -- a UKUUG Special Technical Group for System Administrators. For more information on this conference, contact the conference chair, Neil Todd, at The UK UNIX User Group (UKUUG) is a not-for-profit organization that is independent from hardware and software vendors.

And speaking of LISA: don't forget the USENIX LISA System Administration conference, to take place in Monterey, CA, November 1 to 5. The planning is almost complete now, and the conference looks very promising. The proposals for papers submitted this year were the best ever. Many of the papers are on traditional, technical system administration-related problems, but a good number address the theme of this year's conference -- "The Human Aspect of UNIX System Administration." This year, there will be three parallel tracks, in order to cover topics of interest for both large and small sites, and both new and experienced system administrators. For more information, contact me (as the conference chair) at, or contact the USENIX conference office by email at or call (714) 588-8649.

Book on X Administration

A new release of the book on X administration is fresh off the press from O'Reilly and Associates. The complete title is X Window System System Administrator's Guide, the authors are Linda Mui and Eric Pearce.

And Now to the Questions in This Issue:

 Q Some of our terminals will not redraw the screen correctly when we are using a screen editor such as vi. Other terminals work correctly. Can you explain what the problem might be?

 A The cause of the problem is in the terminal capability database. The shell environment variable TERM is used by any program which needs cursor-addressing functionality in the terminal. The terminal capability database itself is kept in two different formats. On BSD it is kept in a single file, termcap (see Figure 1 for a sample entry), which most commonly is located in /etc, /usr/lib or /usr/share/misc. This file contains an ASCII description of the cursor commands, each consisting of a field name, such as "rv" for reverse video or "na" for no arrow keys. On System V, the principle is very much the same, but here the database is already compiled into a machine-readable format, and each terminal type is kept in a separate file. The files are kept in /usr/lib/terminfo. Theoretically, the System V approach is faster; however, on today's fast machines, there is not much difference, as long as the most commonly used termcap entries are kept towards the beginning of the file. Some systems can keep the current termcap entry in the shell environment variable TERMCAP, so that the terminal capability database only has to be accessed during login. System V provides two programs, tic (terminfo compiler) to compile and infocmp to uncompile (i.e., turn a machine-readable file back into ASCII), and a third program, captoinfo, to convert a termcap description into a terminfo description. These programs allow for local modification/additions to the database. The problem the questioner described can be caused in two possible ways. If the TERM variable is not set correctly during login, then the system will send incorrect cursor-addressing commands to the terminal, causing it to behave incorrectly. If the TERMCAP variable points to a terminal type which is similar to the currently used one, then the terminal will appear to work correctly most of the time, while doing some weird things now and then. The other possibility is that the TERMCAP value is correct, but that the terminal capability entry for that terminal is either incomplete or simply wrong (and, unfortunately, this is not that uncommon). If this is the case, then you will have to fix or rewrite the entry for that terminal. This is not very difficult, as the terminal manufacturer documentation includes a description of the cursor addressing commands. However, it may take a couple of tries before you get it right. A good approach is to start with a similar terminal type, and make whatever modifications are necessary.

 Q We are currently using Sun systems, running SunOS. We have been discussing for some time whether we should migrate to Solaris. What is your suggestion?

 A Boy, that's a loaded question. Sun wants us to believe that we should move to Solaris as fast as possible. However, almost every UNIX system administrator I know is in no hurry to convert, the reason being that there are very significant differences in how the systems are administered. Not only is Solaris based on System V, while SunOs is a BSD-based system, but many files have changed location or been renamed, in relation to both System V rel 3.2 and BSD 4.x. Many of the problems this creates for the system administrator can be remedied by in-depth training on the new system. However, the changes do not stop there, as the differences between SunOs and Solaris are also found in user space. You are therefore not only faced with retraining your users, but may also need to rewrite or patch locally developed shell scripts because of differences in command syntax and naming. To name just a few examples, "ps -ax" is now "ps -ef" and the "lpr" command is named "lp". However, the line printer system in Solaris is based on the System V, and there is nothing which even slightly resembles the BSD line printer system. If you have dealt with the System V line printer system in the past (any System V version), you will probably do okay; otherwise, expect a steep learning curve.

In light of this, it is very difficult to understand why Sun is pushing so hard for Solaris. One of our clients now only purchases Sparcs from a third party, as these machines, unlike true Sun hardware, can still run SunOs 4.x. As a tiny light in the dark, Sun has recently announced it will ship SunOs for the new Sun Classic. Whether this is the beginning of a more sane attitude remains to be seen.

In the meantime, how many sites have converted to Solaris? At a recent meeting of Bay-LISA, we took an informal survey of the people in the room. When we asked how many people were running Solaris at their site, a number of people indicated that they were. However, when we asked how many people were running Solaris on a significant part of their network, only two people indicated that they did so. At this point somebody in the group asked "How many people, outside of Sun, are running a significant number of Solaris systems?" With the question framed this way, the number dropped to zero. I think this is very significant, as the people who attend these meetings represent some of the largest sites in Silicon Valley.

So to answer your question directly: upgrade a few machines to Solaris, so that you can start learning to use and administer the system. However, do this only for two or three machines, and chose machines that have no strategic position in your network. Expect the conversion to be problematic, and delay the general conversion as long as you possibly can. It is a good idea to make it clear to your manager that it will be a lot more costly to administer Solaris than it was for SunOs, at least for some time to come.

 Q I have heard that it is possible to send e-mail by SMTP over UUCP. How is this done?

 A Yes, this is possible, via a process referred to as Batched SMTP or BSMTP (SMTP stands for Small Mail Transfer Protocol and is what sendmail, for example, uses when sending over TCP/IP). The process requires that the remote site be able to accept e-mail in this form. It is done by building a batch file which contains all the SMTP commands necessary for the connection, and then sending them by UUCP. On the remote end, this file is fed to a command that is able to accept the BSMTP file. BSMTP is supported by smail 3.1 (a freely distributable mail agent), but takes some work if you are running sendmail. If you currently are running sendmail on your UUCP gateway, I suggest that you consider replacing it with smail (a drop-in replacement for sendmail which understands UUCP a lot better than sendmail).

 Q I have just recently started to administer a few UNIX systems, and I am concerned about the security issues. What should I be looking for?

 A This is a very large area to attempt to cover in very little space. I will give you a little taste of some of the issues, but you really should get a good book on UNIX security (see the list at the end of this article). In practical terms, the question of which issues you need to be concerned about depends on how much security is enough for your site, and on the kind of connectivity you have to the outside world. If you are connected to the Internet, you will need a firewall in place. You will need to install all security patches as soon as they become available, and keep an eye on the bulletins from CERT about security problems. You must track not only security bulletins regarding your own vendor, but also bulletins about systems based on the same UNIX version (i.e., SVr4 or BSD 4.3), since many problems can be traced back to the original base port. Finally, you will need to keep track of access permissions for system files and directories. I will go into this in some detail, as this is the most fundamental part of this problem.

UNIX system security is based on three groups of file permissions, one each for the file owner, the owner's group, and the world at large. The UNIX system administrator can regulate the access privilege to each file and directory on the system. For each of the three entities -- user, group, and other -- there are three access bits which specify if the file (or directory) is readable, writeable, or executable by the user (yes, I know you cannot execute a directory; I'll get back to the meaning of the execute permission for directories in a bit). In addition to read, write, and execute permissions, there are three other access information flags. A file can be set uid {SUID} or set gid (SGID). If a file has the SUID flag set, it will execute with the permission of the owner of that file, independent of the identification of the user starting the execution. In a similar manner, a file with the SGID flag set will execute with the group permission of the group which owns the file. This is a very powerful feature, as it can be used to give a specific program access permissions for files to which the caller of that program does not have access. An example is the uuname command, which allows a user to list the names of all the hosts to which a system is connected by UUCP without requiring that the user have read access to the UUCP configuration files. In a similar manner, the ps command gives a user limited access to the kernel's internal process tables, without giving the user permission for any other unspecified access to that data.

Unfortunately, the SUID also opens a huge can of worms with respect to security. While it often is tempting to write small programs with SUID to root, it should be avoided whenever possible. In general, use SGID instead of SUID; if SUID is required, SUID to a non-root user if at all possible. If you must write SUID programs, I recommend that you write them in Perl, as Perl protects the programmer from many common pitfalls. I further urge you to never write any SUID or SGID program as a shell script.

You will find a good number of SUID and SGID programs supplied with your system, and you might want to add programs to those. However, you should be wary of SUID programs in the users' file space, especially if they are SUID to root and and have funny names such as "..." or ".. " (dot-dot-dot and dot-dot-space).

To return to general file permissions for a moment -- make sure that each file on the system has the correct permission set. The best thing is to make a baseline printout of the permission of the files in important system directories (such as /bin., /etc, and /usr/bin), and from time to time compare these with the actual content of the system.

Directories use the same permissions scheme, except that the execution flag means to allow search privileges. This can be used in special cases to allow access to files within a directory without giving read permission to that directory. In such a case, a user who knows the full path name can access a particular file, but would not have read access to the directory itself and thus could not do an ls.

Also, be aware of the fact that while a read-only file cannot be modified, it can be moved or removed if the user has write access to the directory. This is very often overlooked by people new to the UNIX access protection scheme, and it can leave imported security holes open, if not attended to.

Recommended UNIX Security Books

Garfinkel, Simson, and Gene Spafford. Practical UNIX Security. Sebastopol, CA: O'Reilly and Associates, 1991.

Curry, Dave UNIX System Security. Reading, MA: Addison Wesley, 1992.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at; or by phone at (408) 241-3111.