6.2 Managing User Accounts

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:

  • Assign the user a username, a user ID number, and a primary group, and decide which other groups she should be a member of (if any). Enter this data into the system user account configuration files.

  • Assign a password to the new account.

  • Create a home directory for the user.

  • Place initialization files in the user's home directory.

  • Use chown and/or chgrp to give the new user ownership of his home directory and initialization files.

  • Set other user account parameters appropriate for your system (possibly including password aging, account expiration date, resource limits, and system privileges).

  • Add the user to any other facilities in use as appropriate (e.g., the disk quota system, mail system, and printing system).

  • Grant or deny access to additional system resources as appropriate, using file protections or the resources' own internal mechanisms (e.g., the /etc/ftpusers file controls access to the ftp facility).

  • Perform any other site-specific initialization tasks.

  • Test the new account.

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.



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).

Table 6-4. Shell and full-name modification commands



Change login shell

Usual: chshSolaris: passwd -e (root use only)

Change full name (GECOS field)

Usual: chfnSolaris: passwd -g (root use only) 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:

  • Use the cd command.

  • Set or change the value of the PATH, ENV, or SHELL variables.

  • 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 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 (~!).

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.

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:

Bourne shell
C shell
.login, .logout, and .cshrc
Bourne-Again shell
.profile, .bash_profile, .bash_login, .bash_logout, and .bashrc
Enhanced C shell
.login, .logout, and .tcshrc (or .cshrc)
Korn shell
.profile and any file specified in the ENV environment variable (conventionally .kshrc)

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:

/etc/security (contains .profile only)

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. Sample login initialization files

The .*login or .*profile files are used to perform tasks that only need to be executed upon login, such as:

  • Setting the search path

  • Setting the default file protection (with umask)

  • Setting the terminal type and initializing the terminal

  • Setting other environment variables

  • Performing other customization functions necessary at your site

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. 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.

Be aware that the Bourne-Again shell (bash) behaves differently depending on whether it is invoked as /bin/sh or not (if so, it emulates the behavior of the traditional Bourne shell in some areas). 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. 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:

  • If the file /etc/sysconfig/desktop exists, its contents are compared to the keywords GNOME, KDE, and AnotherLevel (in this order). If a keyword is found within the file, the corresponding environment is started if it is available. If not, the system attempts to start the GNOME desktop environment, falling back to KDE in the event of failure (for example, if GNOME is not installed).

  • Next, the file .wm_style is searched for in the user's home directory. If it is found and it contains any of the keywords AfterStep, WindowMaker, fvwm95, Mwm or Lesstif (searching in that order and taking only the first match), the corresponding window manager is started if it is available.

  • If nothing else has been selected or is present at this point, the fvwm (tried first) or twm simple window manager is started (the latter is available on virtually every Unix system because it is part of the X11 distribution).

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:

  • In the absence of any .xinitrc file in the user's home directory, the default X initialization file (/usr/lib/X11/xinit/xinitrc) attempts to start the fvwm2, fvwm, and twm window managers (in that order).

  • If the default .xinitrc file (contained in /etc/skel) has been copied to the user's home directory, a different procedure is used. First, the script checks to see whether the environment variable WINDOWMANAGER is set. If so, it uses the path specified as its value as the location of the desired window manager.

    If this environment variable is not set, the initialization file attempts to locate the KDE environment files on the system. If these files cannot be located, those for fvwm2 are tried next, followed by all window managers listed in the file /usr/X11/bin/wmlist.

    The first window manager that is located is set as the value of the WINDOWMANAGER environment variable. As the file concludes, this variable is used to initiate the selected graphical environment. In this way, the SuSE scheme differs from that of Red Hat in that it attempts to start only a single window manager. 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.

All systemwide initialization files should be writable only by the superuser.

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.



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:

  • Adding the user to various security facilities, which may include assigning system privileges. Some of these are discussed later in this chapter.

  • Assigning disk quotas (see Section 15.6).

  • Defining a mail alias and fulfilling any other requirements for the mail system that is in use (see Chapter 9).

  • Setting print-queue access (see Chapter 13).

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.

Table 6-5. Available user account attribute types

Password lifetimes

Password strength

Login times

Login locations

Resource limits





































[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. AIX user account controls

AIX provides several classes of user account attributes, which are stored in a series of files in /etc/security:


Environment variable settings (discussed previously)


Group administrators


Per-account resource limits


Per-tty valid login time and system-wide valid login shells


User passwords and password change data and flags


Per-user account login controls and attributes

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). 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 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. 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. 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.:


Here is the equivalent setting under Tru64:


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. 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):


Lock account

Unlock account


chuser account_locked=true

chuser account_locked=false


chpass -e

chpass -e


passwd -l

edit /etc/passwd manually


passwd -l

passwd -u


passwd -l

edit /etc/shadow manually


usermod -x administrative_lock_applied=1

usermod -x administrative_lock_applied=0

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. 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:

  • Change other passwords that the user knew.

  • Terminate any running processes belonging to the user (possibly after investigating any that appear strange or suspicious).

  • Remove the user from any secondary groups.

  • Remove the user's mail spool file (possibly archiving it first).

  • Define/redefine a mail alias for the user account in the mail aliases file (/etc/aliases) and any include files referenced in it, sending mail to someone else or to the user's new email address, as appropriate. Don't forget to remove the user from any mailing lists.

  • Make sure the user hasn't left any cron or at jobs around. If there is any other batch system in use, check those queues too. See if the user has any pending print jobs, and delete them if she does. (I found an enormous, gratuitous one on one occasion.)

  • Make a backup of the user's home directory and then delete it, change its ownership, move all or part of it, or leave it alone, as appropriate.

  • Search the system for other files owned by the user and handle them as appropriate (find will be helpful here).

  • Remove the user from the quota system or set the account's quota to 0.

  • Remove the user from any other system facilities where her username may be specified (e.g., printer permissions, /etc/hosts.equiv and .rhosts files if they are in use).

  • Perform any other site-specific termination activities that may be necessary.

In most cases, writing a script to perform all of these activities is very helpful and time-saving in the long run.

Essential System Administration
Essential System Administration, Third Edition
ISBN: 0596003439
EAN: 2147483647
Year: 2002
Pages: 162

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net