Linux Users and Groups

Why User Management Matters

Linux is designed for multiple users. Even on a single server, different services, admins, and automation systems may run under different accounts. Good account management improves security, auditing, and operational safety.

Instead of giving every process full root access, Linux encourages controlled access through users, groups, and privilege escalation tools.

Core Identity Commands

Start with the commands that tell you who you are.

whoami
id

whoami prints your current username. id shows your numeric user ID, primary group, and supplementary groups.

Example output:

uid=1001(devops) gid=1001(devops) groups=1001(devops),27(sudo),998(docker)

This tells you not only the user name, but also what groups affect your permissions.

Creating and Removing Users

Use useradd to create a user account.

sudo useradd -m -s /bin/bash deploy

Common options:

• -m creates the home directory
• -s sets the login shell

Set a password with:

sudo passwd deploy

Remove a user with:

sudo userdel deploy
sudo userdel -r deploy

-r also removes the home directory.

Tip: Be careful with userdel -r because it removes the user’s home data too.

Modifying Users with usermod

usermod updates existing accounts.

sudo usermod -aG docker deploy
sudo usermod -s /bin/zsh deploy

The -aG combination appends the user to supplementary groups. This is important: using -G without -a can replace existing group memberships.

Working with Groups

Groups make permission management easier.

Create a group:

sudo groupadd developers

Add a user to it:

sudo usermod -aG developers deploy

Groups are useful when multiple users need access to the same application directories, logs, or deployment scripts.

sudo vs su

sudo

sudo runs a command with elevated privileges, typically as root.

sudo systemctl restart nginx
sudo cat /etc/shadow

It is preferred because it gives controlled, auditable elevation for specific commands.

su

su switches to another user account.

su - deploy
sudo su -

su - starts a full login shell for the target user.

In modern administration, sudo is usually favored over sharing the root password.

Important Account Files

/etc/passwd

/etc/passwd stores basic account information such as username, UID, GID, home directory, and login shell.

cat /etc/passwd

A sample entry looks like this:

deploy:x:1002:1002:Deployment User:/home/deploy:/bin/bash

/etc/shadow

/etc/shadow stores password hashes and password policy information.

sudo cat /etc/shadow

This file is restricted because password hashes are sensitive.

Note: /etc/passwd is readable by normal users on many systems, but /etc/shadow should be protected.

Managing Sudo Access

Sudo permissions are often configured through /etc/sudoers or files in /etc/sudoers.d/.

Always edit sudo rules with:

sudo visudo

visudo checks syntax before saving. That matters because a broken sudoers file can lock administrators out of privileged access.

A common pattern is group-based sudo access, such as allowing members of a sudo or wheel group to elevate privileges.

Real-World Scenarios

Granting Docker Access

A CI user needs to run Docker commands without typing sudo each time.

sudo usermod -aG docker ci-runner

The user may need to log out and back in before the new group membership applies.

Creating a Deployment Account

You might create a dedicated account that owns application files and runs deployment scripts.

sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
sudo usermod -aG developers deploy

This keeps deployment activity separate from personal admin accounts.

Best Practices

• avoid direct root logins when possible
• prefer sudo over sharing root credentials
• assign access through groups instead of one-off permission hacks
• review /etc/passwd, /etc/shadow, and sudo rules carefully
• use service accounts for applications and automation

Test Your Understanding

Exercise 1: Preserving existing groups

Question: Why is usermod -aG docker deploy safer than using -G docker without -a?

Exercise 2: Distinguishing passwd and shadow

Question: Which file from the lesson stores password hashes and therefore needs tighter protection?

Exercise 3: Avoiding broken sudoers files

Question: What is the key reason to use visudo when changing sudo rules?

---

Key takeaways

• useradd is low-level, adduser is the friendly wrapper on Debian and Ubuntu.
• A new group needs a new login to take effect: that is why usermod -aG appears not to work.
• Always -aG, never -G alone. Without -a, you replace every secondary group the user had.
• sudo runs one command with logging; su becomes another user for the rest of the session.
• Prefer sudo -i to su -, because it is logged and does not need the root password.
• /etc/passwd is world-readable; /etc/shadow is not: hashes live in shadow for that reason.
• Use visudo, never a plain editor, on sudoers files: it validates syntax before saving.

---

Frequently Asked Questions

What is the difference between useradd and adduser?

useradd is the low-level binary present on every distribution; it does exactly what you tell it and nothing more, so without flags it creates no home directory and sets no password. adduser is a Perl wrapper on Debian and Ubuntu that asks interactively, creates the home directory, copies /etc/skel, and sets up a matching group, which is what you usually want on a workstation. Scripts should use useradd with explicit flags (-m -s /bin/bash) because it is portable and non-interactive.

Why does usermod -aG not take effect until I log out?

Group membership is attached to your session at login and is not re-read afterwards, so a shell that was already open keeps the group list it started with no matter what you change. Log out and back in, or run newgrp <group> to start a shell with the new membership immediately. For a systemd service, restart the service rather than the session. This is the single most common "the command worked but nothing changed" moment in Linux administration.

What is the difference between -aG and -G in usermod?

-aG appends the listed groups to the user's existing secondary groups. -G replaces them entirely, so usermod -G docker alice removes Alice from every other secondary group she was in, including sudo, which can lock an administrator out of their own machine. The -a is only meaningful with -G, and omitting it is a genuinely destructive mistake. Check the result with groups alice or id alice immediately afterwards.

What is the difference between sudo and su?

sudo runs a single command as another user, defaulting to root, authenticating with your own password and logging what was run. su switches to another user for an entire session and needs that user's password. sudo is preferable for administration: nobody needs to know the root password, permissions can be granted per command in sudoers, and every invocation is recorded in the auth log. Where you genuinely want a root shell, sudo -i gives one with the same audit trail.

What is the difference between /etc/passwd, /etc/shadow and /etc/group?

/etc/passwd holds account records, username, UID, GID, home directory, shell, and is world-readable, because ordinary programs need to map UIDs to names. Password hashes were historically in that file, which meant anyone could copy them and attack offline, so they moved to /etc/shadow, readable only by root, along with expiry and ageing fields. /etc/group lists groups and their secondary members. Edit them with usermod, chage and gpasswd rather than by hand.

How do I give a user sudo access?

Add them to the administrative group: usermod -aG sudo alice on Debian and Ubuntu, or wheel on RHEL-family systems. They must log out and back in for it to apply. For narrower access, add a file under /etc/sudoers.d/ granting specific commands, alice ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, which is better practice than full root for a service operator. Always edit sudoers files with visudo (or visudo -f), since it validates the syntax and a malformed sudoers file locks everyone out.