Systems Administration Chapter 10: Users
Page 231
Chapter
Users

Introduction
Before anyone can use your system, they must have an account. This chapter
examines user accounts and the responsibilities of the Systems Administrators with
regards to accounts. By the end of this chapter you should:
· be aware of the process involved in creating and removing user accounts
· be familiar with the configuration files that UNIX uses to store information about
accounts
· know what information you must have to create an account
· understand the implications of choosing particular usernames, user ids and
passwords
· be aware of special accounts including the root account and the implications of
using the root account
· have been introduced to a number of public domain tools that help with account
management
Other resources
Other material which discusses user and authentication related material includes:
· Guides
The Linux Installation and Getting Started Guide has a section (4.6) on user
management. The Linux Systems Administrators Guide’s chapter 11 also
discusses managing user accounts. The Linux Administration Made Easy Guide
also provides some discussion of account related issues in its chapter 6.
· The customisations and usage guides that come with your Linux distribution also
cover account management issues
What is a UNIX account?
A UNIX account is a collection of logical characteristics that specify who the user is,
what the user is allowed to do and where the user is allowed to do it. These

characteristics include a:
· login (or user) name
· password
· numeric user identifier or UID
· default numeric group identifier or GID
Many accounts belong to more than one group but all accounts have one default
group.
· home directory
· login shell
· possibly a mail alias
Systems Administration Chapter 10: Users
Page 232
· mail file
· collection of startup files
Login names
The account of every user is assigned a unique login (or user) name. The username
uniquely identifies the account for humans. The operating system uses the user
identifier number (UID) to uniquely identify an account. The translation between UID
and the username is carried out reading the
/etc/passwd
file (
/etc/passwd
is
introduced below).
Login name format
On a small system, the format of login names is generally not a problem since with a
small user population it is unlikely that there will be duplicates. However on a large
site with hundreds or thousands of users and multiple computers, assigning a login
name can be a major problem. With a larger number of users it is likely that you may
get a number of people with names with similar components, like David Jones,

Darren Jones.
The following is a set of username guidelines. They are by no means hard and fast
rules, but using some or all of them can make life easier for yourself as the Systems
Administrator, or for your users.
· Unique
This means usernames should be unique not only on the local machine but also
across different machines at the same site. A login name should identify the same
person and only one person on every machine on the site. This can be very hard to
achieve at a site with a large user population, especially if different machines have
different administrators.

The reason for this guideline is that under certain circumstances it is possible for
people with the same username to access accounts with the same username on
different machines. There is an increasing trend for global logons. One
username/password will get users into all of the systems they need for a given
organisation.
· Up to 8 characters
UNIX will ignore or disallow login names that are longer. This is dependent on
which platform you are using.
· Lowercase
Numbers and upper case letters can be used. Login names that are all upper case
should be avoided, as some versions of UNIX can assume this to mean your
terminal doesn't recognise lower case letters and every piece of text subsequently
sent to your display is in uppercase.
· Easy to remember
A random sequence of letters and numbers is hard to remember and so the user
will be continually have to ask the Systems Administrator "what's my username?"
· No nicknames
A username will probably be part of an email address. The username will be one
method by which other users identify who is on the system. Not all the users may

know the nicknames of certain individuals.
· A fixed format
There should be a specified system for creating a username. Some combination of
first name, last name and initials is usually the best. Setting a policy allows you to
Systems Administration Chapter 10: Users
Page 233
automate the procedure of adding new users. It also makes it easy for other users
to work out what the username for a person might be.
Passwords
An account's password is the key that lets someone in to use the account. A password
should be a secret collection of characters known only by the owner of the account.
Poor choice of passwords is the single biggest security hole on any multi-user
computer system. As a Systems Administrator, you should follow a strict set of
guidelines for passwords (after all, if someone can break the root account's password,
your system is going bye-bye). In addition you should promote the use of these
guidelines amongst your users.
Password guidelines
An example set of password guidelines might include:
· use combinations of upper and lower case characters, numbers and punctuation
characters
· don't use random combinations of characters if they break the following two rules
· be easy to remember
If a user forgets their password they can't use the system - guess whom they come
and see? Furthermore, the user SHOULD NOT have to write their password
down.
· be quick to type
One of the easiest and most used methods for breaking into a system is simply
watching someone type in their password. It is harder to do if the password is
typed in quickly.
· a password should be at least 6 characters long

The shorter a password, is the easier it is to break. Some systems will not allow
passwords shorter than a specified length.
· a password should not be any longer than 8 to 10 characters
Most systems will look as if they are accepting longer passwords but they simply
ignore the extra characters. The actual size is system specific, but between eight
and ten characters is generally the limit.
· do not use words from ANY language
Passwords that are words can be cracked (you'll see how later).
· do not use combinations of just words and numbers
Passwords like
hello1
are just as easy to crack as
hello
.
· use combinations of words separated by punctuation characters, or acronyms of
uncommon phrases/song lines
They should be easy to remember but hard to crack. for example
b1gsh1p

· change passwords regularly
But not so often that you forget which password is currently set.
· never reuse passwords
The UID
Every account on a UNIX system has a unique user or login name that is used by
users to identify that account. The operating system does not use this name to identify
the account. Instead each account must be assigned a unique user identifier number
(UID) when it is created. The UID is used by the operating system to identify the
account.
UID guidelines
Systems Administration Chapter 10: Users

Page 234
In choosing a UID for a new user, there are a number of considerations to take into
account including:
· choose a UID number between 500 and 32767 (or 60000)
Numbers between 0 and 499 are reserved by some systems for use by system
accounts. Different systems will have different possible maximum values for UID
numbers. Around 32000 and 64000 are common upper limits. When you use the
supplied utilities to create users, they will allocate a valid UID as part of the
process.
· UIDs for a user should be the same across machines
Some network systems (for example
NFS
) require that users have the same UID
across all machines in the network, otherwise they will not work properly.
· you may not want to reuse a number
Not a hard and fast rule. Every file is owned by a particular user id. Problems arise
where a user has left and a new user has been assigned the UID of the old user.
What happens when you restore from backups some files that were created by the
old user? The file thinks the user with a particular UID owns it. The new user will
now own those files, even though the username has changed.
Home directories
Every user must be assigned a home directory. When the user logs in, it is this home
directory that becomes the current directory. Typically all user home directories are
stored under the one directory. Many modern systems use the directory
/home
. Older
versions used
/usr/users
. The names of home directories will match the username
for the account.

For example, a user
jonesd
would have the home directory
/home/jonesd

In some instances, it might be decided to further divide users by placing users into
different sub-directories.
For example, all staff accounts may go under
/home/staff
while students are placed
under
/home/students
. These separate directories may even be on separate
partitions.
Login shell
Every user account has a login shell. A login shell is simply the program that is
executed every time the user logs in. Normally it is one of the standard user shells
such as Bourne,
csh
,
bash
etc. However it can be any executable program.
One common method used to disable an account is to change the login shell to the
program
/bin/false
. When someone logs into such an account,
/bin/false
is
executed and the
login:

prompt reappears.
Dot files
A number of commands, including
vi
, the mail system and a variety of shells, can be
customised using dot files. A dot file is usually placed into a user's home directory
and has a filename that starts with a
.
(dot). These files are examined when the
command is first executed and modifies how it behaves.
Dot files are also known as
rc
files. As you should've found out by doing one of the
exercises from the previous chapter,
rc
is short for "run command" and is a left over
from an earlier operating system.
Commands and their dot files
Systems Administration Chapter 10: Users
Page 235
Table 10.1 summarises the dot files for a number of commands. The FAQs for the
newsgroup
comp.unix.questions
has others.
Shell dot files
These shell dot files, particularly those executed when a shell is first executed, are
responsible for:
· setting up command aliases
Some shells (for example
bash

) allow the creation of aliases for various
commands. A common command alias for old MS-DOS people is
dir
, usually
set to mean the same as the command
ls -l
.
· setting values for shell variables like
PATH
and
TERM


Filename Command
Explanation
~/.cshrc /bin/csh
Executed every time
C
shell started
~/.login /bin/csh
Executed after .
cshrc
when logging in with
C
shell as the login shell
/etc/profile /bin/sh
Executed during the login of every user that
uses the Bourne shell or its derivatives
~/.profile /bin/sh
Located in user's home directory. Executed

whenever the user logs in when the Bourne
shell is their login shell
~/.logout /bin/csh
Executed just prior to the system logging the
user out (when the
csh
is the login shell)
~/.bash_profile /bin/bash
Located in user's home directory. Executed
whenever the user logs in when the Bourne
Again shell (
bash
) is their login shell
~/.bash_logout /bin/bash
Executed just prior to the system logging the
user out (when
bash
is the login shell)
~/.bash_history /bin/bash
Records the list of commands executed using
the current shell
~/.bashrc /bin/bash
bash
shell configuration file – run every time
a
bash
shell is started (not just when you
login)
~/.forward
incoming mail Used to forward mail to another address or a

command
~/.viminfo Vi
Used to set options for use in
vi

Table 10.1
Dot files
Systems Administration Chapter 10: Users
Page 236
Skeleton directories
Normally all new users are given the same startup files. Rather than create the same
files from scratch all the time, copies are usually kept in a directory called a
skeleton

directory. This means when you create a new account you can simply copy the startup
files from the
skeleton
directory into the user's home directory.
The standard skeleton directory is
/etc/skel
. It should be remembered that the files
in the skeleton directory are dot files and will not show up if you simply use the
command
ls /etc/skel
. You will have to use the
-a
switch for
ls
to see dot files.
Exercises

10.1.
Examine the contents of the
skeleton
directory on your system (if you
have one). Write a command to copy the contents of that directory to
another.
Hint: It's harder than it looks.
10.2.
Use the
bash
dot files to create an alias
dir
that performs the command
ls -al

The mail file
When someone sends mail to a user, that mail message has to be stored somewhere so
that it can be read. Under UNIX, each user is assigned a mail file. All user mail files
are placed in the same directory. When a new mail message arrives it is appended
onto the end of the user's mail file.
The location of this directory can change depending on the operating system being
used. Common locations are:
·
/usr/spool/mail

·
/var/spool/mail

This is the standard Linux location.
·

/usr/mail

·
/var/mail


All mail in the one location
On some sites, it is common for users to have accounts on a number of different
computers. It is easier if all the mail for a particular user goes to the one location. This
means that a user will choose one machine as their mail machine and want all their
email forwarded to their account on that machine.
There are at least two ways by which mail can be forwarded:
· the user can create a
.forward
file in their home directory (see Table 10.1)
· the Systems Administrator can create an alias
Mail aliases
If you send an e-mail message that cannot be delivered (for example you use the
wrong address), typically the mail message will be forwarded to the
postmaster
of
your machine. There is usually no account called
postmaster, postmaster
is a mail
alias.
When the mail delivery program gets mail for
postmaster
it will not be able to find a
matching username. Instead it will look up a specific file, under Linux
/etc/aliases

. This file will typically have an entry like
Systems Administration Chapter 10: Users
Page 237
postmaster: root
This tells the delivery program that anything addressed
postmaster
should actually
be delivered to the user
root
. Take a look at the
/etc/aliases
file on your system
for other aliases.
Site aliases
Some companies will have a set policy for e-mail aliases for all staff. This means that
when you add a new user, you also have to update the aliases file.
For example
The Central Queensland University has aliases set up for all staff. An e-mail with an
address using the format

will be delivered to that
staff member's real mail address.
In my case the alias is

. The main on-campus mail host has an
aliases file that translates this alias into my actual e-mail address

.
Linux mail
The following exercise requires that you have mail delivery working on your system.

You can test whether or not email is working on your system by starting one of the
provided email programs (for example
mail
or
pine
) and send yourself an email
message. You do this by using only your username as the recipient address (no
@
). If
it isn't working, refer to the documentation from Red Hat on how to get email
functioning.
Exercises
10.3.
Send a mail message from the
root
user to your normal user account
using a mail program of your choice.
10.4.
Send a mail message from the
root
user to the address
notHere
. This
mail message should bounce (be unable to be delivered). You will get a
returned mail message. Have a look at the mail file for
postmaster
. Has it
increased?
10.5.
Create an alias for

notHere
and try the above exercise again. If you
have installed
sendmail
, the following steps should create an alias:
- login as root
- add a new line containing
notHere: root
in the file
/etc/aliases

- run the command
newaliases

Systems Administration Chapter 10: Users
Page 238
Account configuration files
Most of the characteristics of an account mentioned above are stored in two or three
configuration files. All these files are text files. Each account has a one-line entry in
the file with each line divided into a number of fields using colons.
Table 10.2 lists the configuration files examined and their purpose. By default, Linux
systems use the shadow utilities suite to provide a more secure method of storing
passwords. This method stores passwords in the
/etc/shadow
file rather than in
/etc/passwd
. On some platforms, the shadow file will exist but its filename will be
different. Why shadow password files are more secure is explained later in the
chapter.
File Purpose

/etc/passwd
The password file, holds most of an account characteristics
including username, UID, GID, GCOS information, login shell,
home directory and in some cases the password
/etc/shadow
The shadow password file, a more secure mechanism for holding
the password, common on modern systems
/etc/group
The group file, holds characteristics about a system's groups
including group name, GID and group members
/etc/gshadow
The
/etc/gshadow
file is readable only by the root user, and
contains an encrypted password for each group, as well as group
membership and administrator information
Table 10.2
Account configuration files
/etc/passwd
/etc/passwd
is the main account configuration file. Table 10.3 summarises each of
the fields in the
/etc/passwd
file. On systems that do not use shadow passwords, the
encrypted password will be stored in the
/etc/passwd
file.
Field Name Purpose
login name The user's login name
encrypted password * Encrypted version of the user's password

(or an
x
if shadow passwords are in use)
UID number The user's unique numeric identifier
default GID The user's default group id
GECOS information No strict purpose, usually contains full
name and address details, sometimes
called the comment field
home directory The absolute path to the directory in which
the user is placed when they log in
login shell The program that is run when the user logs
in
* not on systems with a shadow password file
Table 10.3
/etc/passwd

Systems Administration Chapter 10: Users
Page 239
Exercises
10.6.
Examine your account's entry in the
/etc/passwd
field. What is your
UID, GID? Where is your home directory and what is your login shell?
Everyone can read /etc/passwd
Every user on the system must be able to read the
/etc/passwd
file. This is because
many of the programs and commands a user executes must access the information in
the file. For example, when you execute the

ls -l
command, part of what the
command must do is translate the UID of the file's owner into a username. The only
place that information is stored is in the
/etc/passwd
file.
This is a problem
Since everyone can read the
/etc/passwd
file they can also read the encrypted
password.
The problem isn't that someone might be able to decrypt the password - the method
used to encrypt the passwords is supposedly a one-way encryption algorithm. You
aren't supposed to be able to decrypt the passwords. The problem is, however, that
advances in computing power and parallel computing have shown it is possible to use
the encrypted passwords to work out the actual passwords, as described below.
Password matching
The quickest way to break into a UNIX system is to obtain a dictionary of words and
encrypt the whole dictionary. You then compare the encrypted words from the
dictionary with the encrypted passwords. If you find a match, you know what the
password is.
Studies have shown that with a carefully chosen dictionary, between 10-20% of
passwords can be cracked on any machine. Later in this chapter you'll be shown a
program that can be used by the Systems Administrator to test users' passwords.
An even greater problem is the increasing speed of computers. One modern super
computer is capable of performing 424,400 encryptions a second. This means that all
six-character passwords can be discovered in two days and all seven-character
passwords within four months.
The solution
The solution to this problem is simple: store the encrypted passwords in another file

accessible only to the root user. Remember the
passwd
program is
setuid
root.
This new file is called the shadow file and stores only passwords and password related
information. It can be stored in one of a number of different locations depending on
the version of UNIX you are using. A common location, and the one used by the
Linux shadow password suite, is
/etc/shadow
. By default, when shadow passwords
are used, the more secure
MD5
encryption algorithm is used to encrypt passwords.
During installation of your Linux distribution, you can opt not to use shadow
passwords. Utilities are available which can convert to and from normal passwords to
shadow passwords after installation. Where possible you should use shadow
passwords.
Systems Administration Chapter 10: Users
Page 240
Shadow file format
/etc/shadow
Typically the shadow file consists of one line per user containing the encrypted
password and some additional information, in the following format:
· username
· encrypted password
If this field contains a
*
or
!

the account is locked and the user cannot login. If the
account is new and no password has ever been set, the value is
!!
and the user
cannot login.
· the date the password was last changed
· minimum number of days before the password can be changed again
· maximum number of days before the password must be changed
· number of days until age warning is sent to user
· number of days of inactivity before account should be removed
· absolute date on which the password will expire

The additional information is used to implement password aging which allows an
administrator to force users to change passwords at specified intervals. This will be
discussed later in the security chapter.
Groups
A group is a logical collection of users. Users with similar needs or characteristics are
usually placed into groups. A group is a collection of user accounts that can be given
special permissions. Groups are often used to restrict the access to certain files and
programs to a specified collection of users.
/etc/group
The
/etc/group
file maintains a list of the current groups for the system and the
users that belong to each group. The fields in the
/etc/group
file include:
· the group name
A unique name for the group.
· an encrypted password (this is rarely used today)

If the field contains an
x
, the shadow group passwords are in use.
· the numeric group identifier or GID
· the list of usernames of the group members separated by commas
Shadow Passwords for Groups
/etc/gshadow
Although group passwords are seldom used, shadow passwords are implemented for
group passwords in the file
/etc/gshadow
. In addition to storing the group password,
the following information is maintained:
· The group name
· Encrypted password
This allows users who know the group password to add themselves to the group
with the
newgrp
command. If the value is
!
or
!!
no user can access the group via
the
newgrp
command.