Users and Groups

01 Introduction

Every file you create, every process you run, and every system resource you touch has an owner: the user account under which the operation was performed. Linux tracks this identity at every level, from the read() system call that opens a file to the kill() call that signals a process. The result is a system that can support multiple simultaneous users, enforce separation between them, and apply different policies depending on who is asking.

Users are not the only unit of identity. Every user belongs to one or more groups — collections of accounts that share access to the same resources. Groups allow you to grant access not to individuals but to roles: everyone in the developers group gets write access to the source repository, everyone in the sudo group can run commands as root, everyone in the docker group can manage containers. This is far easier to administer than managing per-user permissions one at a time.

This lesson covers the user account model, the group model, the tools for managing both, the distinction between root and ordinary users, and the discipline of privilege separation that determines when and how elevated privileges should be used. The lesson that follows will show how these identities translate into specific access decisions on files and other resources.

02 Learning objectives

This lesson contributes to U2.3 and to course learning outcomes CLO6 and CLO7.

03 Required reading

• Stevens & Rago — Advanced Programming in the UNIX Environment, 3rd ed., Section 1.7 (users and groups) and Section 4.4 (file ownership, briefly). The classical presentation of the user/group model and how the kernel uses it.
• Linux man pages: man 5 passwd, man 5 group, man 5 shadow, man 8 useradd, man 8 groupadd, man 8 sudo, man 7 capabilities. These are the definitive reference for the account model.
• Nemeth, E., Snyder, G., Whaley, B., & Mackin, D. — UNIX and Linux System Administration Handbook, 5th ed., Chapters 6 (managing users) and 8 (access control). An authoritative survey of administration practice.

04 Core content

4.1 What a user account is

A user account is a record that identifies a principal on the system. Each account has:

Username

A human-readable name, such as alice or deploy. Usernames are what you type at a login prompt, but they are not what the kernel uses for access decisions.

User ID (UID)

A non-negative integer that uniquely identifies the account to the kernel. The UID is what appears in the ownership field of every file and process. The username is a convenience for humans; the UID is the real identity.

Primary group

The group ID (GID) that the account belongs to by default. Every file the user creates will be owned by this group unless changed.

Home directory

The directory the user starts in when they log in. Conventionally /home/<username> for ordinary users, /root for the root account.

Login shell

The program that runs when the user logs in interactively. Usually /bin/bash or /bin/sh for human accounts, or /usr/sbin/nologin for accounts that exist for system purposes and should not be logged into.

Password hash

The hash of the user's password, stored separately from the other account information (see below). Empty or locked for accounts that do not authenticate interactively.

4.2 The account databases

Linux stores account information in a small number of text files. Historically all account data was in a single file; today it is split across several for security and flexibility.

4.3 The format of /etc/passwd

Each line in /etc/passwd describes one account, with seven fields separated by colons:

username:password:UID:GID:GECOS:home:shell

alice:x:1000:1000:Alice Example,,,:/home/alice:/bin/bash
root:x:0:0:root:/root:/bin/bash
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin

Interpreting the fields in the first line:

• alice — the username.
• x — a placeholder. The actual password hash is stored in /etc/shadow. Before shadow passwords were introduced, the hash was here — but because /etc/passwd must be world-readable (many programs need to resolve usernames to UIDs), leaving the hash visible to every user was a serious problem.
• 1000 — the UID. On most modern Linux distributions, human accounts start at UID 1000, system accounts use UIDs below 1000, and the root account is UID 0.
• 1000 — the primary GID. The group with this GID is the user's default group.
• Alice Example,,, — the GECOS field, traditionally holding the user's full name and other information. Subfields are separated by commas; the field is often left empty.
• /home/alice — the home directory.
• /bin/bash — the login shell.

4.4 The format of /etc/shadow

/etc/shadow holds the password hash and password-aging information. Each line has nine fields:

username:hash:last_change:min:max:warn:inactive:expire:reserved

alice:$6$Xk2p9qR3$eHk8...:19645:0:99999:7:::

• username — matches the entry in /etc/passwd.
• hash — the password hash. The format is $algorithm$salt$hash. Common algorithm identifiers: $1$ MD5 (obsolete), $5$ SHA-256, $6$ SHA-512, $y$ yescrypt. A value of ! or * means the account has no usable password and cannot log in with one.
• last_change — days since Jan 1, 1970 that the password was last changed.
• min — minimum days before the password may be changed again.
• max — maximum days before the password must be changed.
• warn — days before expiry that the user is warned.
• inactive — days after expiry before the account is disabled.
• expire — days since Jan 1, 1970 that the account itself expires.

4.5 The format of /etc/group

Groups are stored in /etc/group, with four fields per line:

groupname:password:GID:members

sudo:x:27:alice,bob
developers:x:1001:alice,carol,dave
alice:x:1000:

• sudo — the group name.
• x — a placeholder; group passwords are stored in /etc/gshadow and are rarely used.
• 27 — the group's GID.
• alice,bob — a comma-separated list of users who belong to this group in addition to their primary group.

Note that a user's group membership has two sources:

• Primary group. Recorded as the GID field in /etc/passwd. Every user has exactly one primary group.
• Supplementary groups. Recorded in the members field of /etc/group. A user can belong to any number of supplementary groups.

4.6 UID and GID numbering

Different ranges of UIDs are conventionally used for different purposes:

These are conventions, not enforced by the kernel — but utilities such as useradd follow them by default, and many programs rely on the assumption that ordinary users have UIDs ≥ 1000 and system accounts have UIDs < 1000.

4.7 Root and privilege separation

The user with UID 0 is root, the superuser. Root bypasses the ordinary permission checks: it can read, write, and execute any file regardless of the permission bits; it can signal any process; it can mount file systems, load kernel modules, reconfigure network interfaces, and change any user's password. The kernel recognises root not by the name "root" but by the numeric UID 0.

Root is necessary — someone has to administer the system — but it is also dangerous. An accidental rm -rf / as root will destroy the machine; a compromised process running as root compromises the entire system; a bug in a setuid-root program is a privilege-escalation vulnerability. The security literature contains a well-known statement of the problem:

The only safe way to run a program is with no privileges at all. The second-safest way is to run it as root, because at least you know exactly what you are doing — everything can go wrong.

The practical response is privilege separation: use root privileges only when they are needed, for the shortest possible time, and by the fewest possible processes. Three mechanisms implement this on Linux:

sudo — temporary elevation on demand

sudo lets an authorised user run a specific command as another user (by default, root). The user authenticates with their own password, and the command runs with elevated privileges. What the user may run is defined in /etc/sudoers (or files under /etc/sudoers.d/), and every invocation is logged.

# Run a single command as root
$ sudo apt update

# Run an interactive shell as root (be careful)
$ sudo -i

# Run as a different user
$ sudo -u postgres psql

# Show what commands you are permitted to run
$ sudo -l

Advantages. Per-user, per-command policy. Every use is logged. The user does not need to know the root password. Most importantly, it makes privilege elevation an explicit, deliberate act rather than a standing state.

Limitations. The command still runs with full root privileges (unless capabilities are used, see below). And the sudoers configuration is a frequent source of security bugs when written carelessly.

setuid — a binary runs as the file's owner

A file with the setuid bit set runs with the effective UID of its owner, not of the user who invoked it. When the owner is root (as it typically is), this gives the running process root privileges. The classic example is /usr/bin/passwd: an ordinary user runs it to change their password, and it needs root privileges to update /etc/shadow.

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd
    ^
    setuid bit

Advantages. No administrator involvement required for the user to run the tool; the setuid binary is the tool itself.

Limitations. Setuid binaries are a classic privilege-escalation target. Any bug in them — a buffer overflow, a path-traversal error, a failure to sanitise the environment — can give an attacker root. Modern practice minimises the number of setuid binaries installed, and when possible replaces them with capabilities.

Capabilities — the disaggregated root

Instead of granting a binary all of root's privileges, capabilities grant a specific subset. A program that only needs to bind to a privileged port can be given CAP_NET_BIND_SERVICE and nothing else. A program that only needs to send raw packets can be given CAP_NET_RAW. This is the least-privilege principle applied to privilege elevation.

$ sudo setcap cap_net_bind_service=+ep /usr/local/bin/myserver
$ getcap /usr/local/bin/myserver
/usr/local/bin/myserver cap_net_bind_service=ep

Advantages. Precisely scoped. A compromised binary holds only the capabilities it was given, not all of root. The blast radius of a vulnerability is much smaller.

Limitations. The capability model has around 40 capabilities, some of which (CAP_SYS_ADMIN in particular) are very broad. Administering capabilities correctly requires understanding them in detail. Capabilities are covered in more depth in Lesson 12.5.

4.8 Managing accounts

The tools for managing accounts fall into four groups: users, groups, membership, and password policy.

Creating and modifying users

# Create a user with a home directory and default shell
$ sudo useradd -m -s /bin/bash alice

# Set the user's password
$ sudo passwd alice
New password:
Retype new password:
passwd: password updated successfully

# Add user information to the GECOS field
$ sudo usermod -c "Alice Example" alice

# Add alice to a supplementary group
$ sudo usermod -aG developers alice

# Lock an account (prevent password login)
$ sudo usermod -L alice

# Remove a user and their home directory
$ sudo userdel -r alice

Managing groups

# Create a new group
$ sudo groupadd developers

# Change the group's GID (rarely needed)
$ sudo groupmod -g 1050 developers

# Remove a group
$ sudo groupdel developers

# List a user's group memberships
$ groups alice
alice : alice developers sudo

$ id alice
uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1002(developers)

Password policy

# Show a user's password-aging information
$ sudo chage -l alice
Last password change                                    : Oct 15, 2024
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

# Force a password change every 90 days
$ sudo chage -M 90 alice

# Force a password change on next login
$ sudo chage -d 0 alice

4.9 Viewing identity

Several commands report information about the current user and their groups:

# Your username
$ whoami
alice

# Numeric UID
$ id -u
1001

# Full identity: UID, GID, supplementary groups
$ id
uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1002(developers)

# Effective identity (what the kernel checks for file access)
$ id -un
alice

# Who is currently logged in
$ who
alice    pts/0        2024-10-15 10:22

# A more detailed view of the same
$ w

The distinction between real and effective identity is important: for a setuid-root process, the real UID is the invoking user and the effective UID is root. File access is checked against the effective UID; accountability (for example, signalling) is checked against the real UID. This distinction is explored in detail in Unit 12.

4.10 Secure administration practices

The following practices are standard in any environment where security matters. They translate directly into the disciplines you will use in the laboratories of this course.

1. Never log in as root directly. Log in as your ordinary account and use sudo when needed. Direct root login leaves no accountability trail and encourages careless commands.
2. Use sudo for individual commands. Avoid sudo -i (an interactive root shell) unless you have a specific reason. Per-command elevation is safer and better logged.
3. Create separate accounts for services. A web server should run as www-data (or an equivalent), not as root. Each service gets a UID with only the access it needs.
4. Give each human user their own account. Never share accounts. Shared accounts destroy accountability (who did what?) and complicate access revocation (removing one person's access removes everyone's).
5. Disable the shell for accounts that do not need it. Service accounts should have /usr/sbin/nologin as their shell, so even if a password is set they cannot be used to log in interactively.
6. Remove accounts that are no longer needed. An account created for a temporary purpose and forgotten is an unmonitored entry point. Regular access reviews catch these.
7. Restrict who is in the sudo group. Membership in sudo (or wheel on some distributions) is equivalent to full root access. Every member should be someone you would trust with the root password.
8. Use PAM for password policy. Password complexity, length, and reuse rules are enforced by PAM modules, configured in /etc/pam.d/ and /etc/security/pwquality.conf. Do not rely on users to choose strong passwords.
9. Enable auditing. The audit subsystem can log every command run under sudo, every change to /etc/passwd, and every failed login attempt. This is the evidence trail when something goes wrong.
10. Review the account database periodically. Run cat /etc/passwd and cat /etc/group; check for accounts you do not recognise and group memberships that should have been removed.

4.11 What follows from this

The user and group model is the vocabulary of access control on Linux. Every file has an owner and a group; every process runs under a UID and a set of GIDs; every access decision compares the process's credentials to the resource's ownership. In the next lesson, we will see how this vocabulary translates into the concrete permission bits that appear in the output of ls -l, and how the kernel enforces those bits on every system call.

05 Worked example

To see the user and group model in action, trace what happens when a new developer account is created and added to a team group, then examine how the account interacts with a shared project directory.

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• A user account is a record that identifies a principal to the system. The kernel uses the numeric UID, not the username.
• Account information is stored in /etc/passwd (world-readable) and /etc/shadow (root-only). Groups are in /etc/group and /etc/gshadow.
• Every user has a primary group (in /etc/passwd) and can belong to any number of supplementary groups (in /etc/group). Access is checked against both.
• Root (UID 0) bypasses ordinary permission checks and has full administrative privileges. Root is necessary but dangerous.
• Privilege separation uses three mechanisms: sudo for temporary elevation on demand, setuid for binaries that run as their owner, and capabilities for granting only the specific privileges a program needs.
• Account management tools include useradd, usermod, userdel, groupadd, groupmod, groupdel, and passwd. Always use usermod -aG to append to a group.
• Secure administration practices: never log in as root directly, use sudo for individual commands, create separate accounts for services, use nologin shells, remove unused accounts, and review the account databases periodically.
• Shared project directories use a group plus a setgid bit on the directory so that new files inherit the group and remain accessible to all members.

11 References

• Stevens, W. R., & Rago, S. A. Advanced Programming in the UNIX Environment, 3rd ed., Section 1.7 and Section 4.4. Addison-Wesley, 2013.
• Nemeth, E., Snyder, G., Whaley, B., & Mackin, D. UNIX and Linux System Administration Handbook, 5th ed., Chapters 6 and 8. Addison-Wesley, 2017.
• Linux man pages: man 5 passwd, man 5 shadow, man 5 group, man 5 gshadow, man 8 useradd, man 8 usermod, man 8 groupadd, man 8 sudo, man 5 sudoers, man 8 chage, man 7 capabilities.
• Shotts, W. The Linux Command Line, 5th ed., Chapter 9 (permissions). No Starch Press, 2019.
• Linux kernel documentation: Documentation/admin-guide/ security/, in particular the capabilities documentation.