Adding New Users
6.4 A DDING USERS
Before you create an account for a new user at a corporate, government, or educa-tional site, it’s very important that the user sign and date a copy of your local user agreement and policy statement. (What?! You don’t have a user agreement and pol-icy statement? See page 946 for more information about why you need one and what to put in it.)
6. The only reason we are aware of that someone might want to use the newgrp command under Linux is to set the default group of newly created files.
Adding New Users
6.4 Adding users 103
Users have no particular reason to want to sign a policy agreement, so it’s to your advantage to secure their signatures while you still have some leverage. We find that it takes more effort to secure a signed agreement after an account has been released.
If your process allows for it, have the paperwork precede the creation of the account.
Mechanically, the process of adding a new user consists of four steps required by the system, two steps that establish a useful environment for the new user, and several extra steps for your own convenience as an administrator.
Required:
•
Edit the passwd and shadow files to define the user’s account.•
Add the user to the /etc/group file.•
Set an initial password.•
Create, chown, and chmod the user’s home directory.For the user:
•
Copy default startup files to the user’s home directory.•
Set the user’s mail home and establish mail aliases.For you:
•
Verify that the account is set up correctly.•
Add the user’s contact information and account status to your database.Starting on page 108, we discuss the useradd command and its brethren, which au-tomate some of these steps. However, in the next few sections we go over the steps as you’d execute them by hand. This is mostly so that you can see what the supplied tools are doing. In real life, it’s generally preferable (faster and less error prone) to runuseraddor a similar home-grown script.
You must perform each step as root or use a program such as sudo that allows you to run commands as root. See page 41 for more information about sudo.
Editing the passwd and shadow files
To safely edit the passwd file, run vipw to invoke a text editor on a copy of it. The default editor isvi,but you can specify a different editor by setting the value of your EDITOR environment variable. The existence of the temporary edit file serves as a lock; vipw allows only one person to edit the passwd file at a time, and it prevents users from changing their passwords while the passwd file is checked out. When the editor terminates, vipw replaces the original passwd file with your edited copy.
On Fedora and RHEL systems,vipw automatically asks if you would like to edit the shadowfile after you have edited the passwd file. SUSE, Debian, and Ubuntu sys-tems use vipw -s for this function.
For example, adding the following line to/etc/passwdwould define an account called “tyler”:
tyler:x:2422:2422:Tyler Stevens, ECEE 3-27, x7919,:/home/tyler:/bin/sh
We’d also add a matching entry to /etc/shadow:
tyler:*: : : : : :14974:
This shadow line for tyler has no encrypted password or password aging, and it sets the account to expire on December 31, 2010.
Editing the /etc/group file
We should next create an entry in the /etc/group file for tyler’s personal group, which we will also call “tyler”. This group should have GID 2422 to match tyler’s UID of 2422. This is the default GID we assigned to him in thepasswd file.7
tyler::2422:tyler
Strictly speaking, tyler will be in group 2422 whether or not he is listed in/etc/group, because his passwd entry has already given him this membership. The kernel doesn’t care about the contents of /etc/passwd and /etc/group; it only cares about UID and GID numbers. The main purpose of recording personal groups in thegroup file is to make sure that commands such as ls display the names of these groups correctly. Of course, it’s always nice to have an authoritative list of the groups you have created and the users they include.
If we wanted to assign tyler to additional groups, we would simply add his login name to additional groups within the /etc/group file.
Setting an initial password
Root can change any user’s password with the passwd command:
#passwd user
or
$sudo passwd user Rules for selecting good
passwords are given on page 679.
passwdprompts you to enter a new password and asks you to repeat it. If you choose a short, all-lowercase, or otherwise obviously unsuitable password, passwd will complain and ask you to use something more complex. Most Linux systems also check prospective passwords against a dictionary for added security.
The mkpasswd utility that comes with Don Libes’s expect package makes it easy to generate random passwords for new users. For better or worse, the assignment of a random password “forces” new users to change their passwords immediately, as the random ones are difficult to remember.8 Don’t confuseexpect’s mkpasswd with the standard mkpasswd command, which simply encodes a given string as a password.
7. This naming and numbering is purely conventional; see page 102.
8. The passwords are not truly random, but rather pseudorandom. If one or more passwords in a pseudo-randomly generated sequence are cracked, it may be possible to reverse-engineer the sequence and discover additional passwords. Possible, but probably unlikely in the real world. We’re relatively com-fortable with this risk.
Adding New Users
6.4 Adding users 105
Never leave a new account—or any account that has access to a shell—without a password.
Creating the user’s home directory
Any directory you create as root is initially owned by root, so you must change its owner and group with the chown and chgrp commands. The following sequence of commands would create a home directory appropriate for our example user:
#mkdir /home/tyler
#chown tyler:staff /home/tyler
#chmod 700 /home/tyler
Copying in the default startup files
You can customize some commands and utilities by placing configuration files in a user’s home directory. Startup files traditionally begin with a dot and end with the letters rc, short for “run command,” a relic of the CTSS operating system. The initial dot causes ls to elide these files from directory listings unless the -a option is used;
the files are considered “uninteresting.” Table 6.1 lists some common startup files.
Table 6.1 Common startup files and their uses Command Filename Typical uses
csh/tcsh .login Sets the terminal type (if needed) Sets biff and mesg switches .cshrc Sets up environment variables
Sets command aliases Sets the search path
Sets the umask value to control permissions Sets cdpath for filename searches
Sets the prompt, history, and savehist variables basha .bashrc Similar to .cshrc for bash
.bash_profile Similar to .login for bash vim .vimrc Sets vim editor options emacs .emacs Sets emacs editor options
Sets emacs key bindings mail/mailx .mailrc Defines personal mail aliases
Sets mail reader options
xrdbb .Xdefaults Specifies X11 configuration: fonts, color, etc.
startxb .xinitrc Specifies the initial X11 environment
.Xclients Specifies the initial X11 environment (RHEL, Fedora) xdmb .xsession Specifies the initial X11 environment
a.bash will also read .profile or /etc/profile in emulation of sh.
b. Exact details of X Windows vary with the implementation and window manager in use; see Chapter 22 for more details.
If you don’t already have a set of good default startup files,/usr/local/lib/skel is a reasonable place to put them. Copy in some files to use as a starting point and mod-ify them with a text editor. You may wish to start with vendor-supplied files from the /etc/skeldirectory, if your system provides them. Be sure to set a reasonable default value for umask; we suggest 077, 027, or 022, depending on the friendliness and size of your site.
Depending on the user’s shell, /etc may contain system-wide startup files that are processed before the user’s own startup files. For example, bash reads /etc/profile before processing ~/.bash_profile. For other shells, see the man page for the shell in question for details.
It has become common for the system-wide startup files for shells to look in the /etc/profile.d directory for additional configuration snippets to execute. This con-vention provides a clean way for software packages to specify shell-level defaults.
For example, the /etc/profile.d/colorls.* files on Fedora and RHEL are responsible for the technicolor ls output on those systems. (Yes, they can be safely deleted.) The command sequence for installing startup files for the new user tyler would look something like this:
#cp /usr/local/lib/skel/.[a-zA-Z]* ~tyler
#chown tyler:staff ~tyler/.[a-zA-Z]*
#chmod 600 ~tyler/.[a-zA-Z]*
Note that we cannot use
#chown tyler:staff ~tyler/.*
because tyler would then own not only his own files but also the parent directory “..”
(/home) as well. This is a very common and dangerous sysadmin mistake.
Setting the user’s mail home
It is convenient for each user to receive email on only one machine. This scheme is often implemented with an entry in the global aliases file /etc/mail/aliases or the sendmailuserDB on the central mail server. See Chapter 18 for general information about email; the various ways to implement mail homes are discussed starting on page 542.
Verifying the new login
To verify that a new account has been properly configured, first log out, then log in as the new user and execute the following commands:
$pwd /* To verify the home directory */
$ls -la /* Check owner/group of startup files */
You will need to notify new users of their login names and initial passwords. Many sites send this information by email, but for security reasons that’s usually not a good idea. A new user’s account can be compromised and back-doored before the user has
Adding New Users