LFCA 119 🐧 Real-World Scenario — Managing Users and Permissions

User and group management is the quiet foundation of every Linux system. Before a service can run, before a file can be shared, before anyone can log in, the system must know who exists, what groups they belong to, and what they are allowed to do. This is not glamorous work. It rarely makes headlines. But get it wrong, and you create security holes, broken applications, or users who cannot access the resources they need.

This chapter walks through a complete user and permissions management scenario. You will create users, assign them to groups, configure sudo access for administrative tasks, set up password aging policies, and apply file permissions that enforce the principle of least privilege. Each step exercises a specific competency the LFCA exam tests: user creation commands, group membership, the sudoers configuration, file permission models, and access control lists.

By the end, you will have a repeatable workflow for provisioning new users and a clear mental model of how Linux permissions actually work—not just the commands, but the logic underneath them.

Key point: Linux permissions are evaluated in a specific order: owner, then group, then others. The first matching rule applies. If a user is the file owner, the group permissions are never consulted, even if the user is also in the file’s group.

---

Why user and permissions management matters

The authentication foundation. Linux is a multi-user system by design. Every process, every file, every network connection is associated with a user identity. The /etc/passwd file stores account information: username, UID, home directory, and login shell. The /etc/shadow file stores password hashes, readable only by root. The /etc/group file maps groups to their members. Understanding these files is understanding the identity layer of the entire operating system.

The least privilege principle. No user should have more access than necessary. A web server process does not need to modify system binaries. A developer does not need root access to run tests. A contractor does not need to see other users’ home directories. The permission system enforces these boundaries. Every chmod, chown, and group assignment is an application of least privilege.

The sudo question. The su command requires sharing the root password, which is a poor security practice in any multi-user environment. The sudo command allows users to run specific commands with elevated privileges using their own passwords. Configuring sudo correctly—granting just enough access, no more—is a core system administration skill. The LFCA exam tests this understanding.

The LFCA domain coverage. The LFCA certification covers System Administration Fundamentals, which includes user and group management and file permissions and ownership. The exam expects candidates to know how to create users, assign groups, configure sudo access, and set file permissions using both symbolic and numeric notation.

---

a. Creating users and groups

The first step in provisioning a new user is creating their account. The useradd command is the low-level tool for this purpose. By default, it creates a user with the next available UID, assigns a private group with the same name as the user, and does not create the home directory unless instructed.

# Create user with home directory
sudo useradd -m jsmith

# Create user with specific shell and group
sudo useradd -m -s /bin/bash -G developers jsmith

# Set password
sudo passwd jsmith

The -m flag is critical. Without it, the home directory is not created, and the user will log in to a system that has no place for their files. The -s flag sets the login shell; without it, the user gets the system default, which may be /bin/sh rather than a full-featured shell. The -G flag adds the user to supplementary groups.

Groups are managed with groupadd, groupmod, and groupdel. A group is simply a named collection of users that can be granted permissions collectively.

# Create a group
sudo groupadd developers

# Add user to group (without removing from other groups)
sudo usermod -aG developers jsmith

# Verify group membership
groups jsmith

The -aG combination is essential. Using -G alone replaces all supplementary groups; -aG appends to the existing set. Forgetting the -a is a common mistake that silently removes a user from groups they should belong to.

The user information is stored across three files. /etc/passwd contains the account records, visible to all users. /etc/shadow contains the password hashes, readable only by root. /etc/group contains group definitions and memberships. A user with a UID below 1000 is typically a system account; UIDs 1000 and above are for regular human users.

---

b. Configuring sudo access

The sudo command allows authorized users to execute commands with elevated privileges. Unlike su, which requires the root password, sudo uses the user’s own password and can be configured to grant access to specific commands only.

The sudoers configuration is stored in /etc/sudoers. This file should never be edited directly with a text editor. Instead, the visudo command is used, which validates syntax before saving and prevents the catastrophic mistake of locking all users out of sudo due to a syntax error.

# Edit sudoers safely
sudo visudo

# Or create a file in sudoers.d (recommended)
sudo visudo -f /etc/sudoers.d/jsmith

The sudoers.d directory approach is preferred because files there survive system upgrades and are automatically skipped if they contain syntax errors. A typical entry granting full sudo access looks like this:

# User jsmith may run any command
jsmith ALL=(ALL) ALL

More restrictive entries limit access to specific commands or command groups. The Cmnd_Alias syntax allows grouping related commands.

# Define command aliases
Cmnd_Alias SERVICES = /usr/bin/systemctl start, /usr/bin/systemctl stop, /usr/bin/systemctl restart, /usr/bin/systemctl status

# Grant limited access
jsmith ALL = SERVICES

A user with this configuration can manage services but cannot edit configuration files, install packages, or perform other administrative tasks. This is the least privilege principle in action.

To grant sudo access to a group rather than an individual, prefix the group name with a percent sign:

%developers ALL=(ALL) ALL

This means every member of the developers group has sudo access. Adding a user to the group automatically grants them the access; removing them from the group revokes it.

---

c. Password aging and file permissions

User accounts need lifecycle management. Passwords should expire. Accounts for contractors should have an end date. The chage command configures password aging policies.

# Set password to expire in 90 days
sudo chage -M 90 jsmith

# Set account to expire on a specific date
sudo chage -E 2026-12-31 jsmith

# Require password change on next login
sudo chage -d 0 jsmith

# View current aging policy
sudo chage -l jsmith

The -M flag sets the maximum number of days a password is valid. The -E flag sets the account expiration date. Setting -d 0 forces the user to change their password the next time they log in, which is the correct practice when provisioning a new account with a temporary password.

File permissions are the other half of access control. Every file and directory has three permission categories: user (owner), group, and others. Each category can have read (r), write (w), and execute (x) permissions.

# Symbolic notation
chmod u+x script.sh          # Add execute for owner
chmod go-w file.txt          # Remove write for group and others

# Numeric notation
chmod 755 script.sh          # rwxr-xr-x
chmod 644 document.txt       # rw-r--r--

The numeric system uses values: read = 4, write = 2, execute = 1. Permissions for each category are summed. 755 means owner has 7 (4+2+1, full access), group has 5 (4+1, read and execute), and others have 5.

Ownership is changed with chown and chgrp. The chown command changes both owner and group; chgrp changes only the group.

chown jsmith:developers file.txt    # Change owner and group
chgrp developers file.txt           # Change group only
chown -R jsmith:developers /home/jsmith/project

The -R flag applies changes recursively, which is useful for directories but dangerous if used carelessly—it can change permissions on files that should remain restricted.

When standard permissions are insufficient—when you need to grant access to a specific user who is not the owner and not in the file’s group—access control lists (ACLs) provide a more granular solution.

# Grant read access to a specific user
setfacl -m u:alice:r file.txt

# Grant read and write to a group
setfacl -m g:designers:rw file.txt

# View ACL entries
getfacl file.txt

ACLs extend the permission model beyond the three categories. A file with extended ACLs shows a + after the permissions in ls -l output. This is how you grant access to multiple users without creating new groups or making files world-readable.

---

Complete Example Session

# ============================================
# PART 1: CREATE A USER WITH HOME DIRECTORY
# ============================================
sudo useradd -m -s /bin/bash jsmith
sudo passwd jsmith

# ============================================
# PART 2: CREATE AND ASSIGN GROUPS
# ============================================
sudo groupadd developers
sudo groupadd operations
sudo usermod -aG developers,operations jsmith
groups jsmith

# ============================================
# PART 3: VERIFY USER ACCOUNT FILES
# ============================================
grep jsmith /etc/passwd
sudo grep jsmith /etc/shadow
grep developers /etc/group

# ============================================
# PART 4: CONFIGURE PASSWORD AGING
# ============================================
sudo chage -M 90 jsmith
sudo chage -W 14 jsmith
sudo chage -E 2026-12-31 jsmith
sudo chage -l jsmith

# ============================================
# PART 5: CONFIGURE SUDO ACCESS
# ============================================
sudo visudo -f /etc/sudoers.d/jsmith
# Add: jsmith ALL=(ALL) ALL

# ============================================
# PART 6: TEST SUDO ACCESS
# ============================================
su - jsmith
sudo whoami
exit

# ============================================
# PART 7: SET FILE PERMISSIONS (NUMERIC)
# ============================================
touch /tmp/testfile
chmod 644 /tmp/testfile
ls -l /tmp/testfile

# ============================================
# PART 8: SET FILE PERMISSIONS (SYMBOLIC)
# ============================================
chmod u+x /tmp/testfile
chmod go-w /tmp/testfile
ls -l /tmp/testfile

# ============================================
# PART 9: CHANGE OWNERSHIP
# ============================================
sudo chown jsmith:developers /tmp/testfile
ls -l /tmp/testfile

# ============================================
# PART 10: ACCESS CONTROL LIST
# ============================================
sudo setfacl -m u:alice:r /tmp/testfile
getfacl /tmp/testfile

The ten parts covered the full user management lifecycle: account creation, group assignment, file verification, password aging, sudo configuration, access testing, numeric permissions, symbolic permissions, ownership changes, and ACL configuration.

---

Quick Reference

User Management Commands

Command	Purpose	Example
useradd	Create user	useradd -m -s /bin/bash jsmith
usermod	Modify user	usermod -aG developers jsmith
userdel	Delete user	userdel -r jsmith
passwd	Set password	passwd jsmith
chage	Password aging	chage -M 90 jsmith

Group Management Commands

Command	Purpose	Example
groupadd	Create group	groupadd developers
groupmod	Modify group	groupmod -n newname oldname
groupdel	Delete group	groupdel developers
groups	List memberships	groups jsmith

Permission Commands

Command	Purpose	Example
chmod	Change permissions	chmod 755 script.sh
chown	Change owner	chown jsmith:developers file
chgrp	Change group	chgrp developers file
setfacl	Set ACL	setfacl -m u:alice:r file
getfacl	View ACL	getfacl file

Numeric Permission Values

Value	Permission	Meaning
4	r	Read
2	w	Write
1	x	Execute
7	rwx	Full access
6	rw-	Read and write
5	r-x	Read and execute
0	—	No access

---

Best Practices

✅ Do This:

# Always use -m with useradd to create home
sudo useradd -m -s /bin/bash jsmith                    # ✅

# Use -aG to append to groups
sudo usermod -aG developers jsmith                      # ✅

# Use visudo for sudoers changes
sudo visudo -f /etc/sudoers.d/jsmith                    # ✅

# Set password expiration policies
sudo chage -M 90 jsmith                                 # ✅

# Use ACLs for granular access
sudo setfacl -m u:alice:r file.txt                      # ✅

# Test sudo access after configuration
su - jsmith && sudo whoami && exit                      # ✅

❌ Don’t Do This:

# Forgetting -m creates user without home
sudo useradd jsmith                                     # ❌

# Using -G alone removes existing groups
sudo usermod -G developers jsmith                       # ❌

# Editing sudoers directly
sudo vim /etc/sudoers                                   # ❌

# Setting world-writable permissions
chmod 777 file.txt                                      # ❌

# Ignoring the principle of least privilege
jsmith ALL=(ALL) NOPASSWD: ALL                          # ❌

# Forgetting to verify sudo works
# (user may be locked out)                              # ❌

---

Common Pitfalls

Pitfall	Why It Happens	Fix
User cannot log in	Shell set to /bin/false or /sbin/nologin	usermod -s /bin/bash user
Home directory missing	-m flag omitted with useradd	Create manually or recreate user
User removed from groups	-G used instead of -aG	Re-add with -aG
Sudo syntax error locks everyone out	Direct edit of sudoers	Use visudo; fix from recovery mode
Permissions wrong after copy	cp preserves umask not source	Use cp -p or chmod after
ACL not working	Filesystem not mounted with acl option	Add acl to /etc/fstab

---

Real-World Examples

1. Create Service Account

sudo useradd -r -s /sbin/nologin appuser

2. Add User to Multiple Groups

sudo usermod -aG docker,developers,operations jsmith

3. Set Password Expiry

sudo chage -M 60 -W 7 jsmith

4. Grant Limited Sudo

echo "jsmith ALL=(ALL) /usr/bin/systemctl" | sudo tee /etc/sudoers.d/jsmith

5. Make Script Executable

chmod 755 deploy.sh

6. Secure Sensitive File

chmod 600 ~/.ssh/id_rsa

7. Share Directory with Group

chown root:developers /srv/project
chmod 770 /srv/project

8. Grant ACL Access

setfacl -m u:contractor:rx /srv/project

9. Check User Account Info

id jsmith

10. Lock Compromised Account

sudo passwd -l jsmith

---

Visual

User and Group File Structure

┌─────────────────────────────────────────────────────────────┐
│  THE THREE IDENTITY FILES                                   │
│                                                             │
│  /etc/passwd (world-readable)                               │
│  jsmith:x:1001:1001:John Smith:/home/jsmith:/bin/bash       │
│         │    │    │         │              │                │
│         │    │    │         │              └── Shell        │
│         │    │    │         └── Home dir                    │
│         │    │    └── GID (primary group)                   │
│         │    └── UID                                        │
│         └── Password placeholder (x = see shadow)           │
│                                                             │
│  /etc/shadow (root only)                                    │
│  jsmith:$6$...:19000:0:90:14:...                            │
│                                                             │
│  /etc/group                                                 │
│  developers:x:1002:jsmith,alice                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Permission Evaluation Order

┌─────────────────────────────────────────────────────────────┐
│  HOW LINUX EVALUATES PERMISSIONS                            │
│                                                             │
│  User requests access to file                               │
│    │                                                        │
│    ▼                                                        │
│  Is user the file owner?                                    │
│    │                                                        │
│    ├── YES ──▶ Apply OWNER permissions. STOP.               │
│    │                                                        │
│    └── NO                                                   │
│          │                                                  │
│          ▼                                                  │
│  Is user in the file's group?                               │
│    │                                                        │
│    ├── YES ──▶ Apply GROUP permissions. STOP.               │
│    │                                                        │
│    └── NO                                                   │
│          │                                                  │
│          ▼                                                  │
│  Apply OTHERS permissions                                   │
│                                                             │
│  First match wins. Group permissions never checked          │
│  if user is the owner.                                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

sudo vs su

┌─────────────────────────────────────────────────────────────┐
│  su vs sudo                                                 │
│                                                             │
│  su:                                                        │
│  su -                                                       │
│  Password: [ROOT PASSWORD]                                  │
│  → Full root shell                                          │
│  → Requires sharing root password                           │
│  → Not auditable per-user                                   │
│                                                             │
│  sudo:                                                      │
│  sudo systemctl restart nginx                               │
│  [sudo] password for jsmith: [USER'S OWN PASSWORD]          │
│  → Runs single command as root                              │
│  → No root password sharing                                 │
│  → Audit trail in /var/log/auth.log                         │
│                                                             │
│  Best practice: Use sudo for shared systems.                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Permission Numeric Calculation

┌─────────────────────────────────────────────────────────────┐
│  NUMERIC PERMISSION CALCULATION                             │
│                                                             │
│  Permission    Binary    Value    Sum                       │
│  r (read)      100       4        4                         │
│  w (write)     010       2        2                         │
│  x (execute)   001       1        1                         │
│                                                             │
│  Examples:                                                  │
│  7 = 4+2+1 = rwx (full)                                     │
│  6 = 4+2   = rw- (read/write)                               │
│  5 = 4+1   = r-x (read/execute)                             │
│  4 = 4     = r-- (read only)                                │
│  0 = 0     = --- (no access)                                │
│                                                             │
│  chmod 755 file                                             │
│    Owner: 7 (rwx)                                           │
│    Group: 5 (r-x)                                           │
│    Other: 5 (r-x)                                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Summary

Item	Value
User creation	useradd -m -s /bin/bash username
Password setting	passwd username
Group creation	groupadd groupname
Group membership	usermod -aG groupname username
Password aging	chage -M days username
Account expiry	chage -E YYYY-MM-DD username
Sudo configuration	visudo -f /etc/sudoers.d/username
Permission change	chmod 755 file
Ownership change	chown user:group file
ACL grant	setfacl -m u:user:r file
Identity files	/etc/passwd, /etc/shadow, /etc/group

Key takeaways:

• useradd -m is the correct way to create a user. The -m flag creates the home directory by copying /etc/skel. Without it, the user has no place to store files.
• usermod -aG appends to groups. The -a flag is critical. Without it, the -G flag replaces all supplementary group memberships.
• visudo prevents lockout. Never edit /etc/sudoers directly. A syntax error can prevent all sudo access, including for root. Use visudo -f for individual files in /etc/sudoers.d/.
• Password aging is a security policy. The chage command enforces password rotation, sets account expiration dates, and forces password changes on first login.
• Permissions are evaluated owner first, then group, then others. The first matching category applies. A file owner never gets group permissions, even if they are in the group.
• Numeric permissions are summed values. Read = 4, write = 2, execute = 1. The three digits represent owner, group, and others in that order.
• ACLs extend the permission model. When standard permissions are insufficient, setfacl grants access to specific users or groups without changing ownership or creating new groups.

Remember: User and permission management is the enforcement layer of every security policy. Creating a user is not just running a command; it is establishing an identity with a home directory, a shell, a group membership, and a lifecycle. Setting permissions is not just running chmod; it is deciding who can do what and ensuring that decision matches the principle of least privilege. The LFCA exam tests these commands, but the skill it evaluates is the judgment to apply them correctly. A system with poorly managed users and permissions is not just insecure—it is unpredictable, and unpredictability is the enemy of reliable administration.

---

---

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!