Table of Contents
Linux is a multi-user operating system. Even systems that will be used by a single user are configured as a multi-user system. This has various advantages:
security-wise, your system is protected from malicious software execution as the software is executed as an unprivileged user rather than the system administrator
if at any time multiple users are going to work on the system, you just need to add the user to the system (no need to upgrade to a multi-user environment first)
you can easily back up all files belonging to a particular user as all user files are located inside his home directory
if you messed up your personal configuration for a particular software title, you can just remove the configuration files (or move them aside) and start the software title up again to start with a clean slate. No configuration changes made by a user are propagated system-wide
How you deal with this multi-user environment depends on your needs...
If your system is used by various users, you will need to add or remove their user accounts. Before starting with the command syntax, first a few words on how this information is stored on the Linux system.
A user is identified by his user id, which is an ordinary integer
number. However, it is much easier to use a user name instead of a
number. For this purpose, a Unix/Linux system maps a user name to a user
id. By default, this information is stored within the
/etc/passwd file. However, you can also configure your system to
obtain this information from a central repository (like an LDAP
service), similar to how Windows can be configured to connect to an
passwd file contains a line for every
user. Each line contains 7 fields, separated by colons:
Password, or "x" if the password is stored elsewhere
Primary group ID
Comment or description
The password field on modern systems contains an "x", telling the system
that the password is stored inside the
/etc/shadow file. Storing the passwords elsewhere
is needed to improve the security of the system: the
passwd file should be world readable because many
tools rely on it. Storing the password (even when it is encrypted or
hashed) in a publicly readable file is asking for troubles - tools
exist that attempt to crack user account passwords given the encrypted
/ hashed password values.
For this reason, the hashed password is stored inside the
/etc/shadow file which is only readable by the
root user (system administrator). The tools that work with passwords
are small in number and highly audited to decrease the chance that
they contain any vulnerabilities. More about the shadow file
As you will see in the next section, a user can be a member of many groups. However, every user has a single, primary group: this is the active group at the moment that the user is logged on. The active group defines the group ownership of the resources the user creates while logged on (remember, resources are assigned three ownership groups: user, group and others).
The users' home directory is usually the directory where the user has full write access to (even more, it is most often the only directory where the user has write access to). If a user is logged on through the command line (not graphically), it is also the directory where the user starts to work from.
Finally, the default shell for this particular user is defined. We've talked about what a shell is before. Unix/Linux has several shells, each shell provides roughly the same functionality, but is manipulated differently. Gentoo Linux by default uses the bash shell (bourne again shell), a powerfull shell with lots of additional functions such as command autocompletion, output colouring and more. Smaller shells also exist, such as csh (c shell) or ksh (korn shell).
More information about shells is available online.
shadow file contains all information regarding a users' password.
The most important field for many is the (hashed) password itself, but
other information is available as well. The shadow file, like the
passwd file, has a single line for every user; fields are separated by
Hashed password value
Date of last password change (counted in days since Jan 1, 1970)
Number of days that need to pass before the password can be changed by the user
Maximum number of days since the password change that the password can be used; after this amount of days, the password will need to be changed by the user
Number of days before expiry date (see field 5) that the user will be warned about the pending password change policy
If the password isn't changed after this many days after the forced password change, the account is locked
Date when the account is (or will be) locked (counted in days since Jan 1, 1970)
Reserved field (not used)
If the last three fields are left empty (which is the default case), their enforcement isn't valid.
The password value is hashed, meaning that the password itself is not stored on the disk (nor in any encrypted form). Instead, a mathematical formula is used to create a unique number or string from a password. To verify if a password given by a user matches, the given password is passed through the same mathematical formula and the resulting number or string is matched against the stored string. Such method makes it harder for a user to find out the password even if he has access to the shadow file because he can't deduce the password from the hash value.
Account information can be stored elsewhere - any repository will do, as long as it provides at least the same information as the passwd (and shadow) file. This is important because in enterprise environments, you rather want to keep track of user accounts in a central repository rather than in the files on several hundreds of systems.
/etc/nsswitch.conf file defines where the system can find this
information. An excerpt from an nsswitch.conf file is given below. You
notice that it defines services on every line followed by the
repository (or repositories) that manages the information.
passwd: compat shadow: compat group: compat hosts: files dns
In the example, the passwd, shadow and group services are
managed by the "compat" implementation. Compat is the default
implementation provided by glibc (GNU C Library) which offers access
to the various
/etc/* files. The hosts service
(used to resolve host names to IP addresses and vice versa) is managed
by two implementations:
"files", which is the implementation that offers access to the /etc/hosts file (a table containing IP address and host name(s))
"dns", which is the implementation that offers queries with DNS servers
Group membership is used to group different users who need access to a shared resource: assign the resource to a particular group and add the users to this group.
Similar with the /etc/passwd file, group information is stored inside the /etc/group. Again, every line in this text file defines a group; the fields within a group definition are separated by a colon.
Group password, or "x" if the password is stored elsewhere
Group members (who don't have the group as a primary group)
It might seem strange to have a password on a group. After all, a user logs on using his user name. However, there is a sane reason for this: you can add users to a different group and password-protect this group. If a user is logged on to the system (but doesn't use the particular group as primary group) and leaves his terminal, malicious users can't change to this particular group without knowing the password even if they have access to the users' terminal (and therefore logged on session).
Group passwords aren't used often though. The cases where group passwords can be used (privileged groups) are usually implemented differently (for instance using privilege escalation tools like sudo).
# useradd -D thomas
In the above example, a user account identified by "thomas" is created using the system default settings (which, for a Gentoo Linux system, means that the default shell is bash, the home directory is /home/thomas, etc) after which his password is set.
You can pass on additional arguments to the useradd command to alter the users' attributes (such as the user id, home directory, primary group ...). I encourage you to read the useradd manual page for more information.
# userdel -r thomas
With the -r option, userdel not only removes the user account from the system but also cleans and removes the users' home directory. If you omit this option, the users' home directory remains available on the system, allowing you to keep his (private or not) files for future use.
Once a user account is created, you can't use useradd to add the user to one or more groups.
You will be able to remove groups even though there are still users member of this group. The only check that groupdel performs is to see if a group is a users' primary group (in which case the operation fails).
# groupadd audio
Suppose you want to add or remove a user from a group, you can use the usermod tool (as seen before) or the gpasswd tool.
# gpasswd -a audio thomas
Most resources on a Unix system are protected by a particular group: you need to be a member of a particular group in order to access those resources. The following tables gives an overview of interesting groups.
Table 10.1. Incomplete (!) list of system groups
|Group name||Description / resources|
|wheel||Be able to "su -" to switch to the root user|
|audio||Be able to use the sound card on the system|
|video||Be able to use the graphical card for hardware rendering purposes (not needed for plain 2D operations)|
|cron||Be able to use the system scheduler (cron)|
|cdrom||Be able to mount a CD/DVD|
The passwd command allows you to change or set an accounts' password.
# passwd thomas New UNIX password: (enter thomas' password) Retype new UNIX password: (re-enter thomas' password) passwd: password updated successfully
The root user is always able to alter a users' password. If a user wants to change his own password, the passwd command will first ask the user to enter his current password (to make sure it is the user and not someone who took the users' session in the users' absence) before prompting to enter the new password.
With the tool, you can also immediately expire the users' password
(-e), lock or unlock the account
(-l or -u) and more. In effect,
this tool allows you to manipulate the
On any system, a regular user has little to no rights to perform administrative tasks. However, on a home workstation you'd probably want to be able to shut down the system. You can log on as the root user on a different (virtual) terminal, but you can also elevate your own privileges...
$ su - Password: (Enter the root password) #
In the above example, a regular user has switched his session to become a root session. The "-" argument informs the su command that not only the users' privileges should be switched, but also that the root users' environment should be loaded. Without the "-" option, the regular users' environment would be used.
This environment defines the shell behaviour; its most important setting is the PATH variable which defines where the binaries are located for the commands that this user might summon.
With su, you can also switch to a different user:
$ su thomas - Password: (Enter thomas' password) $
If you just want to execute a single command as a different user, you can use the "-c" argument:
$ su -c "shutdown -h now"
The su-based methods require the user to know the password of the other accounts. On many systems, you might not want this. There are two ways of dealing with such situations: marking a command so that it always runs as a privileged user, or use a tool that elevates privileges without requiring the password for the elevated privilege...
Executable binaries (not shell scripts) can be marked so that the Unix/Linux kernel executes that command as a specific user, regardless of who started the command. This mark is the setuid bit. Once set (using the chmod command), the tool is always executed with the rights of the owner and not the rights of the executor:
# chmod +s /path/to/command
Using setuid tools is generally considered a security risk. It is better to avoid setuid tools when possible and use tools such as sudo, as explained later.
For instance, if the shutdown command is marked setuid, then every user is able to run the shutdown command as root (which is the commands' owner) and thus be able to shut down or reboot the system.
If you mark an executable using the setuid bit, every user can execute the command as the application owner (root). You usually don't want to allow this but rather assign the necessary rights on a per-user, per-command basis. Enter sudo.
The sudo tool allows the system administrator to grant a set of users (individually or through groups) the rights to execute one or more commands as a different user (such as root), with or without requiring their password (for the same reason as the passwd command which asks the users' password before continuing).
All users in the wheel group are allowed to execute any command as root
All users in the operator group are allowed to shut down the system
The test user is allowed to run a script called webctl.ksh without a password
All users in the httpd group are allowed to edit the /etc/apache2/conf/httpd.conf file through sudoedit
%wheel ALL=(ALL) ALL %operator ALL=/sbin/shutdown test ALL=NOPASSWD: /usr/local/bin/webctl.ksh %httpd ALL=(ALL) sudoedit /etc/apache2/conf/httpd.conf
If sudo is set up, users can execute commands by prepending sudo to it. If allowed, some users can even obtain a root shell through the sudo -i command.
(Execute a single command as root) $ sudo mount /media/usb Enter password: (unless configured with NOPASSWD) (Obtain a root shell) $ sudo -i Enter password: (unless configured with NOPASSWD) #