If you cannot control who logs into a Linux server, you might as well leave the front door wide open for anyone to delete your company's entire customer database. That is the problem User and Group Administration solves: it is the lock, the key, and the guest list for every person who needs to touch a computer system. For the XK0-006 exam, understanding how to create, modify, and remove users and groups is not just a box to tick — it is the foundation of Linux security and the very first thing an attacker will try to exploit if you get it wrong.
Jump to a section
A simple way to picture User and Group Administration
A shared flat with eight housemates and a big party happening this weekend.
The flat has one front door with a keypad code. Some housemates should be able to come and go as they please, others should only be allowed in the common areas during the party, and the party guests themselves should only get a temporary code that stops working at midnight. The person who owns the flat, the Landlord, decides who gets which level of access. The Landlord creates a list of 'Trusted Housemates' who can use the main door, the kitchen, and the fancy coffee machine. The Landlord then creates a 'Party Guest' list, and everyone on that list gets a one-time code that only opens the front door and the downstairs loo. The Landlord also needs a way to give the 'Clean-up Crew' access to the cleaning cupboard and the vacuum cleaner, but not the Landlord's private bedroom. Instead of typing out a separate set of rules for each of the eight housemates, the Landlord defines a 'Housemate' role and a 'Guest' role. When a new housemate moves in, the Landlord just puts them in the 'Housemate' group, and instantly that new person has exactly the right keys. When the party ends, the Landlord can just delete the 'Guest' group, and all those temporary keys stop working at once. There is no need to track down each individual guest's phone and manually revoke their codes, because the group system handles it all in one fell swoop.
In the Linux operating system, every running programme and every logged-in person is represented by a user. A user is simply an identity — a string of characters like 'dave' or 'admin' — that the operating system uses to decide what that person is allowed to do. Behind the scenes, the operating system does not actually remember the name 'dave'. It works with a number, called the User ID (UID). When you create a user account, Linux stores the mapping between the name and the UID in a file called /etc/passwd. This file is not a password file despite its name — it is a list of every user account on the system, along with their UID, their default group, their home directory, and the shell programme they use when they log in.
A group is a collection of users. Every user belongs to at least one group, called their primary group. The point of groups is to simplify permission management. You do not want to walk up to every single user and say 'you can read this file, you cannot, you can'. That would be exhausting on a system with hundreds of users. Instead, you create a group called 'developers', put all the developer user accounts into that group, and then set the file's group permission to 'read and write'. Every developer automatically gets that access because they are a member of the group. This is the core reason groups exist: to bundle permissions so that one change to the group affects every member.
When a user logs in, the system reads /etc/passwd to find the user's UID and primary group ID (GID). It then reads /etc/group, which maps group names to GIDs and lists which users are members of each group. The system does not actually authenticate you against /etc/passwd for your password — that is handled by a separate file called /etc/shadow, which stores the hashed (scrambled) version of your password so that even if someone steals the file, they cannot easily reverse it to get your actual secret word. The /etc/shadow file is readable only by the system's most privileged user, the root user, to protect those hashed passwords from prying eyes.
To add a new user, an administrator uses the 'useradd' command. This command creates the user's entry in /etc/passwd, creates their home directory (usually /home/username), copies default configuration files from /etc/skel into that home directory, and sets the user's default shell. To remove a user, the 'userdel' command is used, and to change properties of an existing user, the 'usermod' command is the tool of choice. For groups, the equivalent tools are 'groupadd', 'groupdel', and 'groupmod'. The command 'passwd' is how you set or change a user's password.
There is a special user called 'root'. Root is the superuser, with a UID of 0 (zero). Root can do absolutely anything — read any file, delete any file, change any setting. Because root is so powerful, sensible administrators rarely log in as root. Instead, they use 'sudo' (superuser do), which allows a normal user to run one specific command with root privileges. This is controlled by the /etc/sudoers file. If a user is listed in /etc/sudoers, they can type 'sudo' before a command and temporarily become root for just that one action. This is far safer than staying logged in as root all day, because a typo like 'sudo rm -rf /' could destroy the entire system if executed as root.
The last key concept is the 'umask'. When a user creates a new file, the system applies a default set of permissions. The umask tells the system which permissions to remove. For example, a typical umask of 022 means 'remove write permission for the group and for others'. The practical upshot is that new files are readable by everyone but writable only by the owner. Changing the umask changes the default security for all new files a user creates.
Create a New User
Run 'sudo useradd -m jdoe'. The '-m' flag creates a home directory at /home/jdoe, copies default files from /etc/skel, and sets the default shell. This is the very first step in giving a new person access to the system.
Set the User's Password
Run 'sudo passwd jdoe'. You will be prompted to type and confirm a password. This hashes the password and stores it in /etc/shadow. Without this step, the account exists but no one can log into it.
Create a Group for the User's Team
Run 'sudo groupadd developers'. This adds an entry to /etc/group. Now you have a container that can hold multiple users, which simplifies permission management for team resources.
Add the User to the Secondary Group
Run 'sudo usermod -aG developers jdoe'. The '-a' flag appends the user to the 'developers' group without removing them from any other groups they already belong to. The user must log out and back in for the group change to take effect in their current session.
Assign Group Ownership and Permissions to a Shared Directory
Run 'sudo chgrp developers /srv/project_files' to change the group owner of the directory, then 'sudo chmod 770 /srv/project_files' to give the owner and group read, write, and execute permissions while denying all access to others. Now every member of the 'developers' group can work in that directory.
Force the User to Change Their Password on Next Login
Run 'sudo chage -d 0 jdoe'. This sets the last password change date to the epoch, forcing the system to prompt for a new password the next time the user logs in. This is critical when assigning temporary passwords to new hires.
Imagine you are the lone IT administrator for a small marketing agency with thirty employees and one central Linux server that hosts the company's internal web applications and file shares. The agency just hired five new staff members: three graphic designers, one copywriter, and one data analyst. Your job is to get them productive by the end of their first day.
You start by logging into the server via SSH (Secure Shell — a way to remotely control a Linux machine). You cannot just give everyone the same login because you would never know who deleted a critical file or who accidentally ran a command that crashed the web server. So you create individual accounts.
You run: 'sudo useradd -m -G designers anna'. The '-m' flag tells the system to create Anna's home directory. The '-G designers' flag adds Anna to the 'designers' secondary group. You repeat this for the other two designers: 'sudo useradd -m -G designers ben' and 'sudo useradd -m -G designers chloe'. For the copywriter, you use: 'sudo useradd -m -G copywriters diana'. For the data analyst, you use: 'sudo useradd -m -G analysts edward'.
Now you set their passwords using 'sudo passwd anna' (the system will prompt you to type the password twice). You send each person their temporary password through a separate secure channel — never in the same email as their username.
The company has a directory called /srv/shared_docs. The designers need to write files there, the copywriter needs to read them, and the data analyst should not have any access. You set the directory so that it is owned by the 'designers' group: 'sudo chgrp designers /srv/shared_docs'. Then you set the permissions: 'sudo chmod 770 /srv/shared_docs'. The '770' means: the owner can read, write, and execute; the group (designers) can read, write, and execute; and everyone else (including the data analyst) gets zero permissions. Because the copywriter is not in the designers group, they can still read the files if the files themselves have world-readable permissions — but you can lock that down by setting file permissions carefully. If you later realise the copywriter should also edit these files, you simply run 'sudo usermod -aG designers diana'. The '-aG' flag appends Diana to the designers group without removing her from her current copywriters group. One command, and Diana now has full write access to the shared docs.
A month later, the data analyst leaves the company. You run 'sudo userdel -r edward'. The '-r' flag removes his home directory and his mail spool, leaving no trace on the system. The security police is happy because no orphaned dormant accounts exist that an attacker could exploit. This is the daily reality of user and group administration: a constant cycle of creating, modifying, and deleting accounts to match the ever-changing roster of people who need access to the system.
The XK0-006 exam tests User and Group Administration in a very practical, command-driven way. You will not be asked to write essays about theory. You will be given a scenario and asked to choose the correct command or flag to accomplish a specific task. The exam loves to test the difference between similar commands and the exact flags that cause different behaviours.
Key exam topics:
The distinction between 'useradd', 'usermod', and 'userdel': You must know which command creates, which changes, and which removes. The exam will present a scenario like 'A user named jsmith has left the company. Which command removes the user account and their home directory?' The answer is 'userdel -r jsmith'. A common trap is offering 'useradd -d jsmith' or 'usermod -r jsmith', which are both wrong.
The difference between primary group and secondary group: When you create a user with 'useradd', the system automatically creates a group with the same name as the user and makes it the user's primary group (this is called a 'user private group'). The exam may ask what happens if you use the '-g' flag (specifies primary group) versus the '-G' flag (specifies supplementary groups). A lowercase 'g' versus an uppercase 'G' is a classic trap.
The /etc/sudoers file and the visudo command: You must know that the only safe way to edit the sudoers file is with the 'visudo' command, which locks the file and checks syntax before saving. If you edit sudoers directly, a syntax error could lock you out of using sudo entirely. The exam loves to ask about this.
The /etc/passwd file format: You should know the seven colon-separated fields: username, password placeholder (x means the real password is in /etc/shadow), UID, GID, GECOS (user's full name or description), home directory, and login shell. The exam might show you a line from /etc/passwd and ask what a specific field means.
The /etc/shadow file: It stores the hashed password, plus password ageing information. The exam may ask which file stores the password hash (answer: /etc/shadow, not /etc/passwd).
The 'su' versus 'sudo' commands: 'su' switches the user context entirely (you become the other user), while 'sudo' runs a single command as another user (usually root). The exam tests that 'sudo -i' gives an interactive root shell, similar to 'su -', but with different logging and environment implications.
Password ageing with 'chage': The exam expects you to know how to force a user to change their password on next login using 'sudo chage -d 0 username'. The '-d 0' sets the last password change date to epoch (1 Jan 1970), which forces the system to ask for a new password immediately.
Traps to watch for:
Using lowercase '-g' when uppercase '-G' was required.
Confusing 'useradd' with 'adduser' (adduser is a friendlier script found on Debian-based systems, but the exam standard is 'useradd').
Thinking that deleting a user with 'userdel' without '-r' also deletes the home directory — it does not. The directory remains, causing potential security issues.
Forgetting that 'groupmod -n' renames a group but does not change the files that were associated with the old group name. Those files need their group changed manually with 'chgrp' afterwards.
Every file and process in Linux is owned by a user and a group, and permissions are checked against those identities before any action is allowed.
The 'useradd' command creates a user account, 'usermod' changes an existing account, and 'userdel' removes an account — never use one when you mean another.
Groups exist to bundle permissions so that one change to a group's access applies to every member of that group simultaneously.
Always use 'visudo' to edit the /etc/sudoers file to prevent syntax errors from locking you out of administrative access.
A user's password hash lives in /etc/shadow, not in /etc/passwd, and only root can read it to prevent offline cracking attacks.
Using 'usermod -aG' (with the append flag) adds a user to a supplementary group without removing their existing group memberships.
These come up on the exam all the time. Here's how to tell them apart.
useradd
Creates a brand new user account from scratch
Adds an entry to /etc/passwd and /etc/shadow
Used only once per user at account creation
usermod
Modifies an already existing user account
Updates existing fields in /etc/passwd and /etc/shadow
Used any time an existing user's properties need changing
Primary Group
Specified in the GID field of /etc/passwd
Set with the '-g' (lowercase) flag in useradd
New files created by the user inherit this group by default
Supplementary Group
Listed in the group field of /etc/group
Set with the '-G' (uppercase) flag in useradd or usermod
Grants access to resources shared with that group
su
Switches user context permanently until you type 'exit'
Requires the target user's password (unless running as root)
Does not log commands by default; no audit trail
sudo
Runs a single command as another user (usually root)
Uses the calling user's password (or no password, depending on sudoers)
Logs every command to /var/log/auth.log; provides full audit trail
Mistake
The root user is just another user account with no special powers — it is simply the default account created during installation.
Correct
Root is the superuser with UID 0, which gives it unrestricted access to every system resource, bypassing all permission checks. No other account, regardless of its name, has this power unless it also has UID 0.
On many desktop Linux distributions, you are never prompted to set a root password, and you use sudo instead. This leads beginners to think root is irrelevant or just a normal account. In reality, any account with UID 0 can do anything on the system.
Mistake
If I delete a user with 'userdel username', all their files and their home directory are automatically removed.
Correct
The 'userdel' command without the '-r' flag only removes the user's entry from /etc/passwd and /etc/shadow. The user's home directory and files remain on the filesystem with their UID number as the owner, appearing as orphaned files.
The word 'delete' sounds definitive. Beginners assume the command cleans up everything. The exam explicitly tests this detailed understanding of flags.
Mistake
A user's password is stored directly in the /etc/passwd file.
Correct
Historically this was true, but for decades now the actual hashed password has been stored in /etc/shadow, which is readable only by root. The /etc/passwd file contains an 'x' in the password field as a placeholder.
The filename 'passwd' is misleading. Beginners see the name and assume it holds the password. This is one of the oldest rookie mistakes in Linux administration.
Mistake
Adding a user to a group with 'usermod -G groupname username' just adds the new group without affecting their existing group memberships.
Correct
Using 'usermod -G' without the '-a' (append) flag replaces the user's entire supplementary group list with just the one group you specified. You must use 'usermod -aG groupname username' to add a group without removing existing ones.
Most beginners expect 'add' behaviour from a command that modifies users. The '-a' flag is easy to forget, and the mistake only becomes apparent later when the user mysteriously loses access to resources they previously had.
Mistake
Only the root user can read the /etc/shadow file.
Correct
Actually, any user or programme with the CAP_DAC_OVERRIDE capability (which root has) can read it, and in some configurations, members of the 'shadow' group can also read it. The general principle is that normal unprivileged users cannot read it, but there are edge cases.
The exam often presents an oversimplified statement as the correct answer, but the reality is more nuanced. Beginners latch onto the simple rule and get caught by a trick question that tests a more precise understanding.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'useradd' is the low-level binary command that is standard on all Linux distributions. 'adduser' is a friendly Perl script found on Debian-based systems that prompts for details interactively. The XK0-006 exam expects you to know 'useradd'.
Yes. The user's current login session inherits the group memberships that existed when they logged in. Adding them to a new group only takes effect in new login sessions, unless they use 'newgrp' or 'sg' to start a new shell with the updated group in the current session.
Yes, any non-root user can change their own password by running 'passwd' with no arguments. The system will prompt for the current password and then the new password. This does not require sudo because the passwd command is SUID root, meaning it runs with root privileges automatically.
Do not do that. Linux prevents you from deleting the currently running root account because UID 0 is hard-coded into the system. Even if you managed to remove the entry from /etc/passwd, the system would become unusable because no account would have the privileges needed to administer it.
Many modern distributions like Ubuntu configure sudo during installation and set the root account to have no password set (locked). This encourages the use of sudo for administrative tasks, which provides an audit trail and reduces the risk of catastrophic errors from a constantly logged-in root session.
A service account is a user account that is not tied to a human person, but to a background programme or service, such as a web server or a database. You should create dedicated service accounts for each major service so that if one service is compromised, the attacker does not automatically gain access to resources belonging to another service.
You've finished User and Group Administration. Continue through the XK0-006 study guide to build a complete picture of the exam.
Done with this chapter?