×

Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Essential System Administration, Second Edition
     

Essential System Administration, Second Edition

5.0 2
by 'leen Frisch, Mike Loukides (Editor)
 

Essential System Administration takes an in-depth look at the fundamentals of Unix system administration in a real-world, heterogeneous environment. Whether you are a beginner or an experienced administrator, you'll quickly be able to apply its principles and advice to your everyday problems.The book approaches Unix system administration from the perspective

Overview

Essential System Administration takes an in-depth look at the fundamentals of Unix system administration in a real-world, heterogeneous environment. Whether you are a beginner or an experienced administrator, you'll quickly be able to apply its principles and advice to your everyday problems.The book approaches Unix system administration from the perspective of your job — the routine tasks and troubleshooting that make up your day. Whether you're dealing with frustrated users, convincing an uncomprehending management that you need new hardware, rebuilding the kernel, or simply adding new users, you'll find help in this book. You'll also learn about back up and restore and how to set up printers, secure your system, and perform many other system administration tasks. But the book is not for full-time system administrators alone. Linux users and others who administer their own systems will benefit from its practical, hands-on approach.This second edition has been updated for all major Unix platforms, including SunOS 4.1, Solaris 2.4, AIX 4.1, Linux 1.1, Digital Unix, OSF/1, SCO Unix Version 3, HP/UX Versions 9 and 10, and IRIX Version 6. The entire book has been thoroughly reviewed and tested on all of the platforms covered. In addition, networking, electronic mail, security, and kernel configuration topics have been expanded substantially.Topics covered include:

  • Starting up and shutting down your system
  • Adding new users
  • Managing processes
  • System security
  • Organizing and planning file systems
  • Planning and performing backups
  • Setting up pointers
  • TCP/IP networking
  • Setting up email
  • Adding terminals and disk drives
  • Setting up and using the accounting system

Editorial Reviews


Fatbrain Review

This expanded and enhanced edition covers the essential and fundamental administrative tasks all UNIX system administrators must perform. The areas with new and updated information include networking, electronic mail, security, and kernel configuration.

The book explains the administration of user accounts, task automation, and system resource management. Along the way you learn how to maintain files and disks, plus how to perform backups and network management. This task-oriented tutorial describes email, configuring and building kernels, and performing UNIX accounting. Coverage also includes Linux administration and the similarities and differences between various UNIX systems. The appendices contain additional information on Bourne shell programming, and how to select and install Linux systems.

Product Details

ISBN-13:
9781565921276
Publisher:
O'Reilly Media, Incorporated
Publication date:
09/08/1995
Series:
Nutshell Handbooks Series
Edition description:
Second Edition
Pages:
788
Product dimensions:
7.01(w) x 9.18(h) x 1.52(d)

Read an Excerpt


Chapter 5: User Accounts

Captive Accounts

Sometimes it is desirable to limit what users can do on the system. For example, when users spend all of their time running a single application program, you can make sure they stay there by making that program their login shell (as defined in the password file). Once the login process is complete, that program begins executing, and when they exit from it, they will be automatically logged out.

Not all programs can be used in this way, however. If variable input is required, for example, and there is no single correct way to invoke it, then simply using it as a login shell won't work. UNIX provides a restricted shell to address such problems.

A restricted shell is a modified version of the Bourne or Korn shell. The location of the restricted Bourne shell within the filesystem varies quite a bit:

HP-UX, SCO UNIX: /bin/rsh
AIX, Digital UNIX: /bin/Rsh
IRIX, Solaris: /usr/lib/rsh

The restricted Korn shell is usually /bin/rksh. These files are hard links to the same disk file as the regular shell, but they operate differently when invoked under the alternate names. They are both suitable for creating captive accounts: user accounts that run only an administrator-specified set of actions and log off automatically when they are finished. For example, a captive account might be used for an operator who runs backups via a menu set up by the administrator. Or, a captive account might be used to place users directly into an application program at login. A captive account is set up by specifying the restricted shell as the user's login shell and creating a .profile file to perform the desired actions.

The restricted shell takes away some of the functionality of the normal shell. Specifically, users of a restricted shell may not:

  • Use the cd command.
  • Set or change the value of the PATH variable.
  • Specify a command or filename containing a slash (/). In other words, only files in the current directory can be used.
  • Use output redirection (> or >>).

Given these restrictions, a user running from a captive account will have to stay in whatever directory the .profile file places him. This directory should not be his home directory, to which he probably has write access; if he ended up there, he could replace the .profile file that controls his actions. The PATH variable should be set as minimally as possible.

A captive account must not be able to write to any of the directories in the defined path. Otherwise, a clever user could substitute his own version for one of the commands he is allowed to run, allowing him to break free from captivity. What this means in practice is that the user should not be placed in any directory in the path as his final destination, and that the current directory should not be in the search path if it is writable.

Taking this idea to its logical conclusion, some administrators set up a separate rbin directory--often located as a subdirectory of the captive account's home directory - containing hard links to the set of the commands the captive user is allowed to run, and then set the user's search path to point only there. If you use this approach, however, you need to be careful in choosing the set of commands you give to the user. Many UNIX commands have shell escape features: ways of running another UNIX command from within them. For example, in vi you can run a shell command by preceding it with an exclamation point and entering it at the colon prompt. If a command supports shell escapes, the user can generally run any command, including a nonrestricted shell. While the path you set will still be in effect for commands run in this way, the user is not prevented from specifying a full pathname in a shell escape command. Thus, even a command as seemingly innocuous as more can allow a user to break free from a captive account since a shell command may be run from more (and man) by preceding it with an exclamation point.

Be sure to check the manual pages carefully before deciding to include a command among the restricted set. Unfortunately, shell escapes are occasionally undocumented, although this is most true of game programs. In many cases, shell escapes are performed via an initial exclamation point or tilde-exclamation point (~!)

CAUTION

In general, you should be wary of commands that allow any other programs to be run within them, even if they do not include explicit shell escapes. For example, a mail program might let a user invoke an editor, and most editors allow shell escapes.

Disabling and Removing User Accounts

Users come and users go, but it isn't always completely clear what to do with their accounts in the latter case. For one thing, they sometimes come back. Even when they don't, someone else will probably take their place and may need some of the things that were in progress when they left.

When someone leaves--either a computer system or an entire site-it is a good idea to at least disable their account(s) as soon as you are notified. If the person was dismissed or otherwise left under less-than-ideal circumstances, it is imperative that you do so. Disabling an account is one task that you can do very quickly: simply add an asterisk to the beginning of the encoded password in /etc/passwd or the shadow password file, and they will no longer be able to log in. You can then do whatever else needs to be done to retire or remove their account in whatever haste or leisure is appropriate.

Some systems also allow you to lock an account via the account management tools and in some cases from the command line:

# pasawd -1 chavez IRIX, SCO UNIX, Linux
# chuser login=no chavez AIX

Under Digital UNIX and HP-UX 10, an account may be locked by including the u_lock field in the user's protected password database file (without a trailing @ sign).

Disabling or locking an account rather than immediately removing its password file entry prevents file ownership problems that can crop up when a username is deleted.

When it is clear that the user account is no longer needed, the account can be retired or completely removed from the system. A retired account continues to exist as a UID within the user account databases, but no access is allowed through it. C2 and higher security levels require that accounts be retired rather than removed so that UIDs don't get reused and system audit, accounting, and other records remain unambiguous. Systems providing these security levels include account retiring capabilities within their user account management tools.

In the next subsection, we'll look at the process of removing a user account. Many of the activities discussed there will still need to be done when an account is retired rather than removed.

Removing a user account

UNIX implementations offering built-in commands or administrative tools for adding users also usually offer similar commands/facilities for removing them. For example, the following commands may be used to remove user chavez from the password file(s) of the various systems:

# userdel chavez Solaris and the shadow package (Linux)
# rmuser -p chavez AIX
# /tcb/bin/rmuser chavez SCO UNIX
# removeuser Digital UNIX

The SCO UNIX command requires UIDREUSE be set to YES in /etc/default/login, or it won't remove the user....

Meet the Author

Frisch has been a system administrator for over 15 years. She looks after a very heterogeneous network of UNIX and Windows NT systems.

Customer Reviews

Average Review:

Post to your social network

     

Most Helpful Customer Reviews

See all customer reviews

Essential System Administration, Second Edition 5 out of 5 based on 0 ratings. 2 reviews.
Guest More than 1 year ago
This book provides lots of good technical information about System Administrator tasks, but doesn't get too bogged down in the 'techie stuff.' Written by a Sys Admin, the author in various places throughout the book gives little 'asides' in sidebars detailing either 'tricks of the trade,' or advising fellow sys admins not to take things too seriously. Not only does it give detailed information, it also details the differencies in various Unix commands among different UNIX OS's. While most Unix systems are basically the same, enough of them (AIX, SunOS, System V, Solaris, and Linux) have specific commands for certain tasks. The topics covered in this book include system startup, troubleshooting system crashes (excellent!), adding users and groups, system security issues, mounting and unmounting filesystems, data backup and recovery issues, even a chapter on TCP/IP Network Management. Several years ago I was 'volunteered' to be a System Administrator at a former job and I wish I'd had this book to help me back then.
Guest More than 1 year ago
Being a System Administrator can be a thankless job and one that requires a wealth of knowledge, skill, and even a little bit of psychology. This book (written by a fellow System Administrator) acknowledges that and while it's giving out great technical information is also giving out occasional good common-sense advice about doing Sys Admin work. As always with O'Reilly books, Essential System Administration is full of excellent information. It includes chapters on administrative tools, booting up and/or shutting down a system, adding user accounts, system security, managing system resources, filesystems and disks, and nacking up your system, among other topics. It also devotes a chapter to managing a TCP/IP network. One thing I really liked about this book was in the midst of tremendous technical information was the author's attitude to 'try and have fun' in the midst of all this seriousness. I wish I'd known about this book 8 years ago when I attempted to be a 'part-time' System Administrator at a Northern California company. While this book won't make being a System Administrator job seem like a walk in the park, it will make it easier.