Even if you’re the only actual human being who uses your Linux system, understanding how to manage user accounts is important — even more so if your system hosts multiple users.
User accounts serve a number of purposes on Unix systems. Most prominently, they give the system a way to distinguish between different people who use the system for reasons of identification and security. Each user has a personal account with a separate username and password. As discussed in Section 4.13 in Chapter 4, users may set permissions on their files, allowing or restricting access to them by other users. Each file on the system is “owned” by a particular user, who may set the permissions for that file. User accounts are used to authenticate access to the system; only those people with accounts may access the machine. Also, accounts are used to identify users, keep system logs, tag electronic mail messages with the name of the sender, and so forth.
Apart from personal accounts, there are users on the system who
provide administrative functions. As we’ve seen, the
system administrator uses the root
account to
perform maintenance — but usually not for personal system use.
Such accounts are accessed using the su command,
allowing another account to be accessed after logging in through a
personal account.
Other accounts on the system may not involve human interaction at
all. These accounts are generally used by system
daemons,
which must access files on the system through a specific user ID
other than root
or one of the personal user
accounts. For example, if you configure your system to receive a
newsfeed from another site, the news daemon must store news articles
in a spool directory that anyone can access but only one user (the
news daemon) can write to. No human being is associated with the
news
account; it is an
“imaginary” user set aside for the
news daemon only.
One of the permission bits that can be set on executables is the
setuid bit, which causes the program to be
executed with the permissions of the owner of that file. For example,
if the news daemon were owned by the user news
,
and the setuid bit were set on the executable,
it would run as if by the user news
.
news
would have write access to the news spool
directory, and all other users would have read access to the articles
stored there. This is a security feature. News programs can give
users just the right amount of access to the news spool directory,
but no one can just play around there.
As the system administrator, it is your job to create and manage accounts for all users (real and virtual) on your machine. This is actually a painless, hands-off task in most cases, but it’s important to understand how it works.
Every account
on the system has an entry in the file
/etc/passwd
. This file contains entries, one
line per user, that specify several attributes for each account, such
as the username, real name, and so forth.
Each entry in this file is of the format:
username
:password
:uid
:gid
:gecos
:homedir
:shell
The following list explains each field:
username
A unique character string, identifying the account. For personal
accounts, this is the name the user logs in with. On most systems it
is limited to eight alphanumeric characters — for example,
larry
or kirsten
.
password
An
encrypted representation of the
user’s password. This field is set using the
passwd program to set the
account’s password; it uses a one-way encryption
scheme that is difficult (but not impossible) to break. You
don’t set this by hand; the
passwd program does it for you. Note, however,
that if the first character of the
passwd
field is *
(an asterisk), the account is
“disabled”; the system will not
allow logins as this user. See Section 5.7.5 later in this chapter.
uid
The
user ID, a unique integer the system uses
to identify the account. The system uses the
uid
field internally when dealing with
process and file permissions; it’s easier and more
compact to deal with integers than byte strings. Therefore, both the
uid
and the
username
identify a particular account:
the uid
is more important to the system,
while username
is more convenient for
humans.
gid
The
group ID, an integer referring to the
user’s default group, found in the file
/etc/group
. See Section 5.7.4, later in this chapter.
gecos
Miscellaneous
information about the user,
such as the user’s real name, and optional
“location information” such as the
user’s office address or phone number. Such programs
as mail and finger use this
information to identify users on the system; we’ll
talk more about it later. By the way,
gecos
is a historical name dating back to
the 1970s; it stands for General Electric Comprehensive Operating System. GECOS has nothing to
do with Unix, except that this field was originally added to
/etc/passwd
to provide compatibility with some
of its services.
homedir
The
user’s home
directory, for his personal use; more on this later. When the user
first logs in, her shell finds its current working directory in the
named
homedir
.
shell
The
name of the program to run when
the user logs in; in most cases, this is the full pathname of a
shell, such as
/bin/bash
or
/bin/tcsh
.
Many of these fields are optional; the only required fields are
username
, uid
,
gid
, and
homedir
. Most user accounts have all
fields filled in, but “imaginary”
or administrative accounts may use only a few.
Here are two sample entries you might find in
/etc/passwd
:
root:ZxPsI9ZjiVd9Y:0:0:The root of all evil:/root:/bin/bash aclark:BjDf5hBysDsii:104:50:Anna Clark:/home/aclark:/bin/bash
The first entry is for the root
account. First of
all, notice that the uid of root
is 0. This is
what makes root
root
: the
system knows that uid 0 is
“special” and that it does not have
the usual security restrictions. The gid of root
is also 0, which is mostly a convention. Many of the files on the
system are owned by root
and the
root
group, which have a uid and gid of 0,
respectively. More on groups in a minute.
On many systems, root
uses
the home directory /root
, or just
/
. This is not usually relevant because you most
often use su to access root
from your own account. Also, it is tradition to use a Bourne-shell
variant (in this case /bin/bash
) for the
root
account, although you can use the C shell if
you like. (Shells are discussed in Section 4.5 in Chapter 4.) Be careful, though: Bourne shells and C
shells have differing syntax, and switching between them when using
root
can be confusing and lead to mistakes.
The second entry is for an actual human being, username
aclark
. In this case, the
uid
is 104. The
uid
field can technically be any unique
integer; on many systems, it’s customary to have
user accounts numbered 100 and above and administrative accounts in
the sub-100 range. The gid is 50, which just means that
aclark
is in whatever group is numbered 50 in the
/etc/group
file. Hang on to your horses; groups
are covered Section 5.7.4
later in this chapter.
Home directories are often found in /home
, and
named for the username of their owner. This is, for the most part, a
useful convention that avoids confusion when finding a particular
user’s home directory, but you can technically place
a home directory anywhere. You should, however, observe the directory
layout used on your system.
Note that as the system administrator, it’s not
usually necessary to modify the /etc/passwd
file
directly. Several programs are available that can help you create and
maintain user accounts; see Section 5.7.5, which
follows.
To some
extent, it is a security risk to let everybody with access to the
system view the encrypted passwords in
/etc/passwd
. Special crack programs are
available that try a huge number of possible passwords and check
whether the encrypted version of those passwords is equal to a
specified one.
To overcome this potential security risk, shadow
passwords have been invented. When shadow passwords are
used, the password field in /etc/passwd
contains
only an x
or a *
, which can
never occur in the encrypted version of a password. Instead, a second
file called /etc/shadow
is used. This file
contains entries that look very similar to those in
/etc/passwd
, but contain the real encrypted
password in the password field. /etc/shadow
is
readable only by root
, so normal users do not have
access to the encrypted passwords. The other fields in
/etc/shadow
, except the username and the
password, are present as well, but normally contain bogus values or
are empty.
Note that in order to use shadow passwords, you need special versions of the programs that access or modify user information, such as passwd or login. Nowadays, most distributions come with shadow passwords already set up so that this should not be a problem for you. Debian users should use “shadowconfig on” instead to ensure that shadow passwords are enabled on their systems.
There are two tools for converting
“normal” user entries to shadow
entries and back. pwconv takes the
/etc/passwd
file, looks for entries that are not
yet present in /etc/shadow
, generates shadow
entries for those, and merges them with the entries already present
in /etc/shadow
.
pwunconv is rarely used because it gives you less
security instead of more. It works like pwconv,
but generates traditional /etc/passwd
entries
that work without /etc/shadow
counterparts.
You
might
think that having two means
of user authentication, /etc/passwd
and
/etc/shadow
, is already enough choice, but you
are wrong in this case. There are a number of other authentication
methods with strange names, such as Kerberos authentication (so named
after the dog from Greek mythology that guards the entrance to Hell).
While we think that shadow passwords provide enough security for
almost all cases, it all depends on how much security you really need
and how paranoid you want to be.
The problem with all those authentication methods is that you cannot simply switch from one to another because you always need a set of programs, such as login and passwd, that go with those tools. To overcome this problem, the Pluggable Authentication Methods (PAM) system has been invented. Once you have a PAM-enabled set of tools, you can change the authentication method of your system by reconfiguring PAM. The tools will automatically get the code necessary to perform the required authentication procedures from dynamically loaded shared libraries.
Setting up and using PAM is beyond the scope of this book, but you can get all the information you need from http://www.kernel.org/pub/linux/libs/pam/. Most modern distributions will set up PAM for you as well.
User groups are a convenient way to logically organize sets of user accounts and allow users to share files within their group or groups. Each file on the system has both a user and a group owner associated with it. Using ls -l, you can see the owner and group for a particular file, as in:
rutabaga% ls -l boiler.tex
-rwxrw-r-- 1 mdw megabozo 10316 Oct 6 20:19 boiler.tex
rutabaga%
This file is owned by the user mdw
and belongs to
the megabozo
group. We can see from the file
permissions that mdw
has read, write, and execute
access to the file; that anyone in the megabozo
group has read and write access; and that all other users have read
access only.
This doesn’t mean that mdw
is in
the megabozo
group; it simply means the file may
be accessed, as shown by the permission bits, by anyone in the
megabozo
group (which may or may not include
mdw
).
This way files can be shared among groups of users, and permissions can be specified separately for the owner of the file, the group to which the file belongs, and everyone else. An introduction to permissions appears in Section 4.13 in Chapter 4.
Every user is assigned to at least one group, which you specify in
the gid
field of the
/etc/passwd
file. However, a user can be a
member of multiple groups. The file /etc/group
contains a one-line entry for each group on the system, very similar
in nature to /etc/passwd
. The format of this
file is:
groupname
:password
:gid
:members
Here, groupname
is a character string
identifying the group; it is the group name printed when using
commands such as ls -l.
password
is an optional encrypted password
associated with the group, which allows users not in this group to
access the group with the newgrp command. Read on
for information on this.
gid
is the group ID used by the system to
refer to the group; it is the number used in the
gid
field of
/etc/passwd
to specify a user’s
default group.
members
is a comma-separated list of
usernames (with no whitespace in between), identifying those users
who are members of this group, but who have a different
gid
in /etc/passwd
.
That is, this list need not contain those users who have this group
set as their “default” group in
/etc/passwd
; it’s only for
users who are additional members of the group.
For example, /etc/group
might contain the
following entries:
root:*:0: bin:*:1:root,daemon users:*:50: bozo:*:51:linus,mdw megabozo:*:52:kibo
The first entries, for the groups root
and
bin
, are administrative groups, similar in nature
to the “imaginary” accounts used on
the system. Many files are owned by groups, such as
root
and bin
. The other groups
are for user accounts. Like user IDs, the group ID values for user
groups are often placed in ranges above 50 or 100.
The password
field of the
group
file is something of a curiosity. It
isn’t used much, but in conjunction with the
newgrp
program it allows users who
aren’t members of a particular group to assume that
group ID if they have the password. For example, using the command:
rutabaga%newgrp bozo
Password:password for group bozo
rutabaga%
starts a new shell with the group ID of bozo
. If
the password
field is blank, or the first
character is an asterisk, you receive a permission denied
error if you attempt to newgrp
to that group.
However, the password
field of the
group
file is seldom used and is really not
necessary. (In fact, most systems don’t provide
tools to set the password for a group; you could use
passwd to set the password for a dummy user with
the same name as the group in /etc/passwd
and
copy the encrypted password
field to
/etc/group
.) Instead, you can make a user a
member of multiple groups simply by including the username in the
members
field for each additional group.
In the previous example, the users linus
and
mdw
are members of the bozo
group, as well as whatever group they are assigned to in the
/etc/passwd
file. If we wanted to add
linus
to the megabozo
group as
well, we’d change the last line of the previous
example to:
megabozo:*:52:kibo,linus
The command groups tells you which groups you belong to, as in:
rutabaga% groups
users bozo
Giving a list of usernames to groups lists the groups to which each user in the list belongs.
When you log in, you are automatically assigned to the group ID given
in /etc/passwd
, as well as any additional groups
for which you’re listed in
/etc/group
. This means you have
“group access” to any files on the
system with a group ID contained in your list of groups. In this
case, the group permission bits (set with chmod
g+...) for those files apply to you (unless
you’re the owner, in which case the owner permission
bits apply instead).
Now that you know the ins and outs of groups, how should you assign
groups on your system? This is really a matter of style and depends
on how your system will be used. For systems with just one or a
handful of users, it’s easiest to have a single
group (called, say, users
) to which all personal
user accounts belong. Note that all the system groups — those
groups contained within /etc/group
when the
system is first installed — should probably be left alone.
Various daemons and programs may depend upon them.
If you have a number of users on your machine, there are several ways
to organize groups. For example, an educational institution may have
separate groups for students, faculty, and staff. A software company
might have different groups for each design team. On other systems,
each user is placed into a separate group, named identically to the
username. This keeps each pigeon in its own hole, so to speak. Files
can also be assigned to special groups; many users create new groups
and place files into them for sharing the files between users.
However, this requires adding users to the additional groups, a task
that usually requires the system administrator to intervene (by
editing /etc/group
or using utilities, such as
gpasswd on Debian systems). It’s
really up to you.
Another situation in which groups are often used is special hardware
groups. Let’s say that you have a scanner that is
accessed via /dev/scanner
. If you do not want to
give everybody access to the scanner, you could create a special
group called scanner
, assign
/dev/scanner
to this group, make this special
file readable for the group and nonreadable for everybody else, and
add everybody who is allowed to use the scanner to the
scanner
group in
the /etc/groups
file.
Creating
a user
account requires several steps: adding an entry to
/etc/passwd
, creating the
user’s home directory, and setting up the
user’s default configuration files (such as
.bashrc
) in her home directory. Luckily, you
don’t have to perform these steps manually; nearly
all Linux systems include a program called adduser
to do this for you.[16]
Running adduser as root
should
work as follows. Just enter the requested information at the prompts;
many of the prompts have reasonable defaults you can select by
pressing Enter:
Adding a new user. The username should not exceed 8 characters in length, or you many run into problems later. Enter login name for new account (^C to quit):norbert
Editing information for new user [norbert] Full Name:Norbert Ebersol
GID [100]:117
Checking for an available UID after 500 First unused uid is 501 UID [501]:(enter)
Home Directory [/home/norbert]:(enter)
Shell [/bin/bash]:(enter)
Password [norbert]:(norbert's password)
Information for new user [norbert]: Home directory: [/home/norbert] Shell: [/bin/bash] Password: [(norbert's password)
] uid: [501] gid: [117] Is this correct? [y/N]:y
Adding login [norbert] and making directory [/home/norbert] Adding the files from the /etc/skel directory: ./.emacs -> /home/norbert/./.emacs ./.kermrc -> /home/norbert/./.kermrc ./.bashrc -> /home/norbert/./.bashrc ... more files ...
There should be no surprises here; just enter the information as requested or choose the defaults. Note that adduser uses 100 as the default group ID, and looks for the first unused user ID after 500 (500 is used as the minimum on SuSE and Red Hat, Debian uses 1000). It should be safe to go along with these defaults; in the previous example we used a group ID of 117 because we designated that to be the group for the user, as well as the default user ID of 501.
After the account is created, the files from
/etc/skel
are copied to the
user’s home directory.
/etc/skel
contains the
“skeleton” files for a new account;
they are the default configuration files (such as
.emacs
and .bashrc
) for the
new user. Feel free to place other files here if your new user
accounts should have them.
After this is done, the new account is ready to roll;
norbert
can log in, using the password set using
adduser. To guarantee security, new users should
always change their own passwords, using passwd,
immediately after logging in for the first time.
root
can set the password for any user on the
system. For example, the command:
passwd norbert
prompts for a new password for norbert
, without
asking for the original password. Note, however, that you must know
the root
password in order to change it. If you
forget the root
password entirely, you can boot
Linux from an “emergency floppy,”
and clear the password
field of the
/etc/passwd
entry for root
.
See Section 8.6 in
Chapter 8.
Some Linux systems provide the command-line-driven useradd instead of adduser. This program requires you to provide all relevant information as command-line arguments. If you can’t locate adduser and are stuck with useradd, see the manual pages, which should help you out.
Deleting a
user
account is much easier than creating one; this is the well-known
concept of entropy at work. To delete an account, you must remove the
user’s entry in /etc/passwd
,
remove any references to the user in /etc/group
,
and delete the user’s home directory, as well as any
additional files created or owned by the user. For example, if the
user has an incoming mailbox in /var/spool/mail
,
it must be deleted as well.
The command userdel (the yin to useradd’s yang) deletes an account and the account’s home directory. For example:
userdel -r norbert
will remove the recently created account for
norbert
. The -r
option forces the
home directory to be removed as well. Other files associated with the
user — for example, the incoming mailbox,
crontab
files, and so forth — must be
removed by hand. Usually these are quite insignificant and can be
left around. By the end of this chapter, you should know where these
files are, if they exist. A simple way to find the files associated
with a particular user is through the command:
find / -user username
-ls
This will give an ls -l listing of each file owned
by username
. Of course, to use this, the
account associated with username
must
still have an entry in /etc/passwd
. If you
deleted the account, use the -uid
num
argument instead, where
num
is the numeric user ID of the dearly
departed user.
Temporarily (or not-so-temporarily)
disabling
a user
account, for whatever reason, is even simpler. You can either remove
the user’s entry in /etc/passwd
(leaving the home directory and other files intact), or add an
asterisk to the first character of the
password
field of the
/etc/passwd
entry, as so:
aclark:*BjDf5hBysDsii:104:50:Anna Clark:/home/aclark:/bin/bash
This will disallow logins to the account in question. Note that if
you use shadow password, you need to do the same thing in
/etc/shadow
.
Modifying
attributes
of user accounts and groups is usually a simple matter of editing
/etc/passwd
and /etc/group
.
Many systems provide commands such as usermod and
groupmod to do just this; it’s
often easier to edit the files by hand.
To change a user’s password, use the
passwd command, which will prompt for a password,
encrypt it, and store the encrypted password in the
/etc/passwd
file.
If you need to change the user ID of an existing account, you can do
this by editing the uid field of /etc/passwd
directly. However, you should also chown the files
owned by the user to that of the new uid. For example:
chown -R aclark /home/aclark
will set the ownership for all files in the home directory used by
aclark
back to aclark
, if you
changed the uid for this account. If ls -l prints
a numeric user ID, instead of a username, this means there is no
username associated with the uid owning the files. Use
chown to fix this.
[16] Note that some Linux systems,
such as Red Hat or SuSE, use a different set of tools for account
creation and deletion. If the sequence of inputs in this section does
not work for you, check the documentation for your distribution. (Red
Hat allows accounts to be managed through the
control-panel tool, and SuSE does it via
YaST; Debian includes a noninteractive
“adduser” script that automatically
sets up users based on the configuration file
/etc/adduser.conf
). In addition, there are
graphical user management programs like kuser from
KDE (see Chapter 11).