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 neil@pio.gid.co.uk. 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 bjorn@sysadmin.com, or contact the USENIX conference office by email at conference@usenix.org 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:
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.
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 bjorn@sysadmin.com; or by phone at (408) 241-3111.
|
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?
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.