Essential System Administration, Third Edition
| In this section, we will consider the processes of adding, configuring, and removing user accounts on Unix systems. 6.2.1 Adding a New User Account
Adding a new user to the system involves the following tasks:
We will consider each of these steps in detail in this section. This discussion assumes that you'll be adding a user by hand. Few people actually do this anymore, but it is important to understand the whole process even if you use a tool that automates a lot of it for you. The available tools are discussed later in this chapter. 6.2.2 Defining a New User Account
The process of creating a new user account begins by deciding on its basic settings: the username, UID, primary group, home directory location, login shell, and so on. If you assign UIDs by hand, it is usually easiest to do so according to some scheme. For example, you could choose the next available UID, assignUIDs from each range of 100 by department, or do whatever makes sense at your site. In any case, once these parameters have been chosen, the new account may be entered into the password file. NOTE If you decide to edit the password file directly, keep the entries within it ordered according to user ID. New entries will be easier to add, and you'll be less likely to create unwanted duplicates. 6.2.3 Assigning a Shell
As we've seen, the final field in the password file specifies the login shell for each user. If this field is empty, it usuallydefaults to /bin/sh, the Bourne shell.[7] On Linux systems, this is a link to the Bourne-Again shell bash (usually /usr/bin/bash). [7] Or the superficially similar POSIX shell (which more closely resembles the Korn shell). Users can change their login shell using the chsh command (or a similar command; see Table 6-4), and the system administrator may also use chsh to set or modify this password file field. For example, the following command will change user chavez's login shell to the enhanced C shell: # chsh -s /bin/tcsh chavez For this purpose, the legal shells are defined in the file /etc/shells; only programs whose pathnames are listed here may be selected as login shells by users other than root.[8] Here is a sample /etc/shells file: [8] This is actually a configuration option of the chsh command, so this restriction may or may not be enforced on your system. /bin/sh /bin/csh /bin/false /usr/bin/bash /usr/bin/csh /usr/bin/ksh /usr/bin/tcsh Most of these shells are probably familiar to you. The unusual one, /bin/false, is a shell used to disable access to an account;[9] it results in an immediate logout to any account using it as a login shell. [9] More accurately, the false command always exits immediately, with a return value signifying failure (the value 1). When this command is used as a login shell, the described behavior results. You may add additional entries to this file, if necessary. Be sure to specify a full pathname (in which no directory component is world-writable).
6.2.3.1 Captive accounts
Sometimes it is desirable to limit what users can do on the system. For example, when users spend all their time running a single application program, you can make sure that's all they do by making that program their login shell (as defined in the password file). After the user successfully logs in, the program begins executing, and when the user exits from it, they are automatically logged out. Not all programs can be used this way, however. If interactive input is required, for example, and there is no single correct way to invoke the program, 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 name and location of the restricted Bourne shell within the filesystem vary, but it is usually /bin/Rsh (often a link to /usr/bin/Rsh). rksh is the restricted Korn shell, and rbash is the restricted Bourne Again shell. These files are hard links to the same disk file as the regular shell, but they operate differently when invoked under the alternate names. AIX and Tru64 provide Rsh, HP-UX and Solaris provide rksh, and Linux systems provide rbash. Some shells let you specify restricted mode with a command-line flag (e.g., bash -restricted). Restricted shells are suitable for creating captive accounts: user accounts that run only an administrator-specified set of actions and that are logged 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:
Given these restrictions, a user running from a captive account must 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 executable 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 the current directory should not be in the search path if the current directory 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 commands the captive user is allowed to run. Then the administrator sets 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 commands: ways of running another Unix command from within the command. For example, in vi you can run a shell command by preceding it with an exclamation point and entering it at the colon prompt (when available, the restricted version, rvi, removes this feature). If a command supports shell escapes, the user can generally run any command, including a unrestricted 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, because 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 (~!).
6.2.4 Assigning a Password
Sincepasswords play a key role in overall system security, every user account should have a password. The passwd command may be used to assign an initial password for a user account. When used for this purpose, it takes the relevant username as its argument. For example, the following command assigns a password for the user chavez: # passwd chavez You are prompted for the password twice, and it does not appear on the screen. The same command may also be used to change a user's password, should this ever be necessary (for example, if she forgets it). Criteria for selecting good passwords and techniques for checking password strength and specifying password lifetimes are discussed later in this chapter, after we have finished our consideration of creating user accounts. Under AIX, whenever the superuser assigns a password to an account with passwd (either manually or indirectly via SMIT), that password ispre-expired, and the user will be required to change it at the next login. Traditionally, Unix passwords were limited to a maximum length of 8 characters. Recent systems, including FreeBSD and Linux when using the MD5 encoding mechanims, and HP-UX and Tru64 in enhanced security mode, allow much longer ones (at least 128 characters). AIX and Solaris still currently limit passwords to 8 characters. 6.2.5 Creating a Home Directory
After adding a user to the /etc/passwd file, you must create a home directory for the user. Use the mkdir command to create the directory in the appropriate location, and then set the permissions and ownership of the new directory appropriately. For example: # mkdir /home/chavez # chown chavez.chem /home/chavez # chmod 755 /home/chavez On Unix systems, user home directories conventionally are located in the /home directory, but you may place them in any location you like. 6.2.6 User Environment Initialization Files
Next, you should give the user copies of the appropriate initialization files for the shell and graphical environment the account will run (as well as any additional files needed by commonly used facilities on your system). The various shell initialization files are:
These files must be located in the user's home directory. They are all shell scripts (each for its respective shell) that are executed in the standard input stream of the login shell, as if they had been invoked with source (C shells) or . (sh, bash, or ksh). The .profile, .bash_profile, .bash_login, and .login initialization files are executed at login.[10] .cshrc, .tcshrc, .bashrc, and .kshrc are executed every time a new shell is spawned. .logout and .bash_logout are executed when the user logs out. [10] The bash shell executes as many of .bash_profile, .bash_login, and .profile as exist in a user's home directory (in that order). As administrator, you should create standard initialization files for your system and store them in a standard location. Conventionally, the directory used for this purpose is /etc/skel, and most Unix versions provide a variety of starter initialization files in this location. These standard initialization files and the entire directory tree in which they are kept should be writable only by root. Here are the locations of the skeleton initialization file directories on the various systems:
In any case, you should copy the relevant file(s) to the user's home directory after you create it. For example: # cp /etc/skel/.bash* /home/chavez # cp /etc/skel/.log{in,out} /home/chavez # cp /etc/skel/.tcshrc /home/chavez # chown chavez.chem /home/chavez/.[a-z]* There are, of course, more clever ways to do this. I tend to copy all the standard initialization files to a new account in case the user wants to use a different shell at some later point. It is up to the user to modify these files to customize her own user environment appropriately. Depending on how you use your system, several other initialization files may be of interest. For example, many editors have configuration files (e.g., .emacs), as do user mail programs. In addition, the Unix graphical environments use various configuration files. 6.2.6.1 Sample login initialization files
The .*login or .*profile files are used to perform tasks that only need to be executed upon login, such as:
The contents of a simple .login file are listed below; it will serve to illustrate some of its potential uses (which we have indicated with comments): # sample .login file limit coredumpsize 0k # suppress core files umask 022 # set default umask mesg y # enable messages via write biff y # enable new mail messages # add items to the system path setenv PATH "$PATH:/usr/local/bin:~/bin:." setenv PRINTER ps # default printer setenv EDITOR emacs # preferred editor setenv MORE -c # make more always clear screen # set an application-specific environment variable setenv ARCH_DIR /home/pubg95/archdir/ # set command prompt to hostname plus current command number set prompt = '`hostname`-\!> ' # very simple terminal handling echo -n "Enter terminal type: "; set tt=$< if ("$tt" == "") then set tt="vt100" endif setenv TERM $tt We can create a very similar .profile file: # sample .profile file ulimit -c 0 umask 022 mesg y biff y PATH=$PATH:usr/local/bin:$HOME/bin:. PRINTER=ps EDITOR=emacs MORE=-c ARCH_DIR=/home/pubg95/archdir/ PS1="`hostname`-\!> " export PATH PRINTER EDITOR MORE ARCH_DIR PS1 echo -n "Enter terminal type: "; read tt if [ "$tt" = "" ]; then tt="vt100" fi export TERM=$tt The main differences are in the ulimit command, the different syntax for environment variables (including the export commands), and the different mechanism for obtaining and testing user input. 6.2.6.2 Sample shell initialization files
Shell initialization files are designed to perform tasks that need to be executed whenever a new shell is created. These tasks include setting shell variables (some of which have important functions; others are useful abbreviations) and defining aliases (alternate names for commands). Unlike environment variables such as TERM, shell variables andaliases are not automatically passed to new shells; therefore, they need to be established whenever the operating system starts a new shell. The contents of a simple .cshrc file are illustrated by this example: # sample .cshrc file alias j jobs # define some aliases alias h history alias l ls -aFx alias ll ls -aFxl alias psa "ps aux | head" # the next alias shows the method for including a replaceable # command line parameter within an alias definition: \!:1 => $1 alias psg "ps aux | egrep 'PID|\!:1' | more -c" # set shell variables to specified various features set history = 100 # remember 100 commands set savehist = 100 # save 100 commands across logins set nobeep # never beep! set autologout 60 # logout after 1 hour idle time set noclobber # warn about overwriting files set ignoreeof # don't interpret ^D as logout set prompt = "`hostname-\!>> " # set prompt If you are using the enhanced C shell, tcsh, you might modify the last two commands and add a couple of others: set correct cmd # try to correct mistyped commands set ignoreeof 2 # 2 ^D's => logout set rmstar # confirm rm * commands set prompt="%m:%~-%h>> " # prompt is: hostname:dir-cmd_num>> The Bourne-Again shell similarly uses .bashrc as its shell initialization file. In the Korn shell, a shell initialization file may be defined via the ENV environment variable (usually in .profile): export ENV=$HOME/.kshrc An alternate shell initialization file can be specified for bash via theBASH_ENV environment variable. Both of these shells define aliases using a slightly variant syntax; an equal sign is included between thealias and its definition: alias l="ls -lxF" Consult the documentation for any of the shells to determine all of the available options and features and the shell variables used enable them.
6.2.6.3 The AIX /etc/security/environ file
AIX provides an additional configuration file where you may set environment variables that are applied to the user's process at login. Here is a sample stanza from that file: chavez: userenv = "MAIL=/var/spool/mail/chavez,MAILCHECK=1800" sysenv = "NAME=chavez@dalton" This entry specifies three environment variables for user chavez, specifying her mail spool folder, how often to check for new mail (every 30 minutes), and the value of the NAME environment variable, respectively. The userenv and sysenv entries differ in that the latter may not be modified. If you include an entry named default in this file, its settings will be applied to all users who do not have an explicit stanza of their own. 6.2.6.4 Desktop environment initialization files
System administrators are frequently asked to provide configuration files that initialize a user's graphical environment. These environments are all based on the X window system, and its most commonly used initialization files are named .xinitrc, .xsession, and .Xauthority. Specific window managers and desktop environments also generally support one or more separate configuration files. For example, the Common Desktop Environment (CDE) uses the .dtprofile initialization file, as well as many files below the ~/.dt subdirectory. Commercial Unix versions generally install CDE as the default windowing system. Unix versions available for free allow users to choose from several offerings, usually at installation time (FreeBSD works this way). On Linux systems, the systemwide X initialization files dynamically choose a desktop environment when X is started. For example, on Red Hat Linux systems, in the absence of any other configuration, desktop initialization occurs via the file /etc/X11/xinit/xinitrc, which then runs /etc/X11/xinit/Xclients. The latter file uses the following process to determine which environment to start:
As you can see, the default process tries to start a fancy graphical environment first, falling back to various simpler ones if necessary. What happens on SuSELinux systems depends on the specifics of how the user account was created:
6.2.6.5 Systemwide initialization files
For Bourne, Bourne-Again, and Korn shell users, the file /etc/profile serves as a systemwide initialization file that is executed before the user's personal login initialization file. The PATH variable is almost always defined in it; it therefore applies to users without explicit PATH variables set in their .profile. Sometimes a default umask is also specified here. Here is a simple /etc/profile file designed for the bash shell, adapted from a Red Hat Linux system; we have annotated it with comments: PATH="$PATH:/usr/X11R6/bin" PS1="[\u@\h \w]\\$ " # prompt: [user@host dir]$ ulimit -c 0 # suppress core files # set umask, depending on whether UPGs are used or not alias id=/usr/bin/id # shorthand to save space if [ `id -gn` = `id -un` -a `id -u` -gt 99 ]; then umask 002 # UID=GID>99 so it's a UPG else umask 022 fi USER=`id -un` unalias id # remove id alias LOGNAME=$USER MAIL="/var/spool/mail/$USER" HOSTNAME=`/bin/hostname` HISTSIZE=100 HISTFILESIZE=100 export PATH PS1 USER LOGNAME MAIL HOSTNAME HISTSIZE HISTFILESIZE # execute all executable shell scripts in /etc/profile.d for i in /etc/profile.d/*.sh ; do if [ -x $i ]; then . $i fi done unset i # clean up Under Red Hat Linux, the files in the installed /etc/profile.d directory initialize the user's language environment and also set up various optional facilities. The system administrator may, of course, add scripts to this directory, as desired.
The tcsh shell also hassystemwide initialization files: /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. AIX supports an additional systemwide initialization file, /etc/environment (in addition to /etc/security/environ, mentioned earlier). This file is executed by init and affects all login shells via the environment they inherit from init. It is used to set the initial path and a variety of environment variables. NOTE The best way to customize systemwide initialization files is to create your own scripts that are designed to run after the standard scripts complete. Hooks are sometimes provided for you. For example, on SuSE Linux systems, /etc/profile automatically calls a script named /etc/profile.local, if it exists, as its final action. Even if your version of the initialization file does not have such a hook, it is easy enough to add one (via the source or . command, depending on the shell). This approach is preferable to modifying the vendor-supplied file itself since future operating system upgrades will often replace these files without warning. If all you've added to them is a simple call to your own local, systemwide initialization script, it will be easy to insert the same thing into the new version of the vendor's file. On the other hand, if you do decide to modify the original files, be sure to keep a copy of your modified version in a safe location so that you can restore it or merge it into the new vendor file after the upgrade. 6.2.7 Setting File Ownership
After you copy the appropriate initialization files to the user's home directory, you must make the new user the owner of the home directory and all its files and subdirectories. To do this, execute a command like this one: # chown -R chavez:chem /home/chavez The -R ("recursive") option changes the ownership on the directory and all the files and subdirectories it contains, all the way down. Note that the second component of chown's first parameter should be the user's primary group. 6.2.8 Adding the User to Other System Facilities
The user should also be added to the other facilities in use at your site. Doing so may involve the following activities:
Any other site-specific user account tasks, for local or third-party applications, should ideally be performed as part of the account creation process. 6.2.9 Specifying Other User Account Controls
Many systems provide additional methods for specifying various characteristics of user accounts. The sorts of controls includepassword change and content, valid login times and locations, and resource limits. Table 6-5 lists the general sorts of account attributes provided by the various Unix flavors.
[11] Functionality is provided by the PAM facility (discussed later in this chapter). We will defer consideration of password-related account controls until later in this chapter. In this section, we'll consider available controls on when and where logins can occur and how to set user account resource limits in other context of each operating system. We'll also consider other settings related to the login process as appropriate. 6.2.9.1 AIX user account controls
AIX provides several classes of user account attributes, which are stored in a series of files in /etc/security:
The contents of all of these files may be modified with the chuser command and from SMIT. We'll look at several of these file in this subsection and at /etc/security/passwd and the password-related controls in /etc/security/user later in this chapter. Here are two sample stanzas from /etc/security/user: default: admin = false Is an administrative user. login = true Can login locally. daemon = true Can run cron/SRC processes. rlogin = true Can connect with rlogin. su = true Users can su to this account. sugroups = ALL Groups that can su to this user. logintimes = ALL Valid login times. ttys = ALL Valid terminal locations. umask = 022 Default umask. expires = 0 Expiration date (0=never). account_locked = false Account is not locked. loginretries = 0 Unlimited tries before account is locked. chavez: admin = true admingroups = chem,bio Groups she administers. expires = 1231013004 Account expires 1:30 A.M. 12/31/04 loginretries = 5 Lock account after 5 login failures. logintimes = 1-5:0800-2000 User can log in M-F, 8 A.M.-6 P.M. The first stanza specifies default values for various settings. These values are used when a user has no specific stanza for her account and when her stanza omits one of these settings. The second stanza sets some characteristics of user chavez's account, including an expiration date and allowed login times. Here is a sample stanza from /etc/security/limits, which sets resource limits for user processes: chavez: fsize = 2097151 core = 0 cpu = -1 data = 262144 rss = 65536 stack = 65536 nofiles = 2000 The default stanza specifiesdefault values. Resource limits are discussed in detail in Section 15.2. The /etc/security/login.cfg file contains login-related settings on a per-tty basis. Here is a sample default stanza: default: logintimes = Valid login times (blank=all). logindisable = 10 Disable terminal after 10 unsuccessful tries. logindelay = 5 Wait 5*#tries seconds between login attempts. logininterval = 60 Reset failure count after 60 seconds. loginreenable = 30 Unlock a locked port after 30 minutes (0=never). This file also contains the list of valid shells in its usw stanza (as noted previously). 6.2.9.2 FreeBSD user account controls
FreeBSD uses two additional configuration files to control user access to the system and to set other user account attributes. The first of these, /etc/login.access , controls system access by user and/or system and/or tty port. Here are some sample entries: +:chavez:dalton.ahania.com Chavez can login from dalton. +:users:.ahania.com The users group can log in from this domain. -:ALL EXCEPT wheel:console Only administrators on the console. The three fields hold + or - (for allow and deny), a list of users and/or groups, and a login origination location, respectively. The order of entries within this file is important: the first matching entry is used. Thus, the example file would not work properly, because users who are not members of the wheel group would still be able to log in on the console due to the second rule. We would need to move the third entry to the beginning of the file to correct this. In general, entries should move from the most specific to the most general. The /etc/login.conf is used to specify a wide variety of user account attributes. It does so by defining user classes, consisting of named groups of settings. User accounts are assigned to a class via the fifth field in the /etc/master.passwd file. The following example file defines three classes, the default class, used for users not assigned to a specific class, and the classes standard and gauss: default:\ # Initial environment settings :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :nologin=/etc/nologin:\ :requirehome:\ :setenv=PRINTER=picasso,EDITOR=emacs: :path=/bin /usr/bin /usr/X11R6/bin ...:\ :umask=022:\ # Login time and origin settings :times.allow=MoTuWeThFr0700-1800,Sa0900-1700:\ :ttys.deny=console:\ :hosts.allow=*.ahania.com:\ # System resource settings :cputime=3600:\ :maxproc=20:\ :priority=0:\ # Password settings :passwd_format=md5:\ :minpasswordlen=8: standard:\ :tc=default: gauss:\ :cputime=unlimited:\ :coredumpsize=0:\ :priority=1:\ :times.allow=:times.deny=: :tc=default: The default class contains settings related to the initial user environment (login messages file, the location for the nologin file, settings for environment variables, and the umask), allowed and/or denied login times, originating ttys and/or hosts (denials take precedence over allows if there are conflicts), system resource settings (see Section 15.2 for more information) and settings related to password encoding, selection and lifetimes (discussed later in this chapter). The standard class is equivalent to the default class since its only attribute is the tc capability include directive (used to include the settings from one entry within another). The gauss class defines a more generous maximum CPU-usage setting, disables core file creation, sets the default process priority to 1 (one step lower than normal), and allows logins all of the time. Its final attribute also includes the settings from the default class. The preceding attributes act as overrides to the default settings since the first instance of an attribute within an entry is the one that is used. After editing the login.conf file, you need to run the cap_mkdb command: # cap_mkdb -v /etc/login.conf cap_mkdb: 9 capability records 6.2.9.3 Linux user account controls
On Linux systems, the file /etc/login.defs contains settings related to the general login process anduser account creation and modification. The most important entries in this file are described in the following annotated example file: ENV_PATH path Search paths for users and root. ENV_ROOTPATH path FAIL_DELAY 10 Wait 10 seconds between login tries. LOGIN_RETRIES 5 Maximum number of login attempts. LOGIN_TIMEOUT 30 Seconds to wait for a password. FAILLOG_ENAB yes Record login failures in /var/log/faillog. LOG_UNKFAIL_ENAB yes Include usernames in the failure log. LASTLOG_ENAB yes Record all logins to /var/log/lastlog. MOTD_FILE /etc/motd;/etc/motd.1 List of message-of-the-day files. HUSHLOGIN_FILE .hushlogin Name of hushlogin file (see below). DEFAULT_HOME yes Allow logins when user's home is inaccessible. UID_MIN 100 Minimum/maximum values for UIDs/GIDs UID_MAX 20000 (used by the standard user account GID_MIN 100 creation tools). GID_MAX 2000 CHFN_AUTH no Don't require a password to use chfn. CHFN_RESTRICT frw Allow changes to full name and office and work phones. The HUSHLOGIN_FILE setting controls whether any message-of-the-day display can be suppressed on a per-user basis. If this parameter is set to a filename without a path (traditionally .hushlogin), these messages will not be displayed if a file of that name is present in the user's home directory (the file's contents are irrelevant). This parameter may also be set to a full pathname, for example, /etc/hushlogin. In this case, its contents are a list of usernames and/or login shells; when a user logs in, if either the user's login name or shell is listed within this file, the messages will not be displayed. In addition to the settings listed in the sample file, /etc/login.defs includes several other settings related to user passwords; we will consider them later in this chapter. See the manual page for login.defs for additional information about the contents of this configuration file. 6.2.9.4 Solaris login process settings
Solaris supports a systemwide login process configuration file, /etc/default/login. Here are some of the most useful login-related settings within it: CONSOLE=/dev/console If defined, limits logins on this tty to root. TIMEOUT=300 Abandon login attempt after 5 minutes. SYSLOG=YES Log root logins and login failures to syslog. SLEEPTIME=4 Wait 4 seconds between failed logins. SYSLOG_FAILED_LOGINS=1 Generate syslog record at second failure. 6.2.9.5 Specifying login time restrictions under HP-UX and Tru64
HP-UX and Tru64 allow the system administrator to specify when during a day, week, or other time period a user's account may be used. This is done with the u_tod attribute in the protected password database. For example, the following entry from an HP-UX system generally allows access on weekdays and during the day (6 A.M. to 6 A.M.) on the weekend but forbids access on any day between 2 A.M. and 5 A.M.: u_tod=Wk0500-2359,Sa0600-1800,Su0600-1800 Here is the equivalent setting under Tru64: u_tod=Wk,Sa-Su0600-1800,Never0200-0500 The Never keyword supported by Tru64 allows for a more compact description of the same restrictions. 6.2.10 Testing the New Account
Minimally, you should try logging in as the newuser. A successful login will confirm that the username and password are valid and that the home directory exists and is accessible. Next, verify that the initialization files have executed: for example, look at the environment variables, or try an alias that you expect to be defined. This will determine if the ownership of the initialization files is correct; they won't execute if it isn't. (You should test the initialization files separately before installing them into the skeleton directory.) Try clearing the terminal screen. This will test the terminal type setup section of the initialization file. 6.2.10.1 Using su to re-create a user's environment
The su command is ideal for some types of testing of newly created accounts. When given a username as an argument, su allows a user to temporarily become another user (root is simply the default username to change to when none is specified). Under the default mode of operation, most of the user environment is unchanged by the su command: the current directory does not change, values of most environment variables don't change (including USER), and so on. However, the option - (a minus sign alone) may be used to simulate a full login by another user without actually logging out yourself. This option is useful for testing new user accounts and also when you are trying to reproduce a user's problem. For example, the following command simulates a login session for user harvey: # su - harvey ******************************************************* ** Regular Maintenance from 20:00 - 23:00 today ** ******************************************************* harvey@phoenix /home/harvey>> clear In addition to its usefulness for new-account testing, such a technique is very handy when users complain about "broken" commands and the like. Once testing is complete, the new user account is ready to use. 6.2.11 Disabling and Removing User Accounts
Users come and users go, but it isn't always completely clear what to do with their accounts when they leave. For one thing, they sometimes come back. Even when they don't, someone else will probably take their place and may need files related to projects that were in progress when they left. When someone stops using a particular computer or leaves the organization, it is a good idea to 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[12] in 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. [12] By adding an asterisk to the beginning of the password field, you can even restore the account at a later time with its password intact, should that be appropriate. This is an example of the recommended practice of making an action reversible whenever possible and practical. On many systems, you can also lock an account from the command line using the passwd command's -l option. Locking an account via an administrative command generally uses the same strategy of prepending a character to the encoded password. For example, the following command locks user chavez's account: # passwd -l chavez 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. On some systems, the passwd command's -u option may be used to unlock a locked user account; changing the user's password also has the side effect of unlocking the account. Here are the specifics for the systems we are considering (all commands take the username as their final argument):
On FreeBSD systems, you can disable an account by setting the account expiration date to a date in the past with chpass -e, or you can edit the shadow password file manually. On HP-UX and Tru64 systems running enhanced security, a user account is locked via the u_lockprotected password database attribute (where u_lock means locked, and u_lock@ means unlocked), rather than via the password modification mechanism. When it is clear that the user account is no longer needed, theaccount can either be retired or completely removed from the system (by deleting the user's home directory and changing ownerships of all other files he owned). A retired account continues to exist as a UID within the user account databases,[13] but no access is allowed through it; its password is set to asterisks and its expiration date is often set to the date the user departed. You will also want to change the login shell to /bin/false to prevent access via Kerberos or ssh. [13] C2 and higher U.S. government 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. 6.2.11.1 Removing a user account
When removing or retiring a user from the system, there are several other things that you might need to do, including the following:
In most cases, writing a script to perform all of these activities is very helpful and time-saving in the long run. |