Linux Users, Groups, and Others: The Complete Guide to File Permissions

Introduction

You're trying to access a file in your colleague's home directory. You have read and execute permissions on the file itself, but you still get a "Permission denied" error. Why?

The answer lies in understanding how Linux manages file ownership and permissions through a three-tier system: Users, Groups, and Others. This foundational concept confuses developers daily, but once you grasp it, you'll troubleshoot permission issues in seconds and design secure access controls confidently.

In this deep dive, we'll unpack how Linux stores user identities, manages group memberships, and enforces permissions—then walk through real-world scenarios that clarify everything.

---

How Linux Identifies You

Every process running on your system has an identity: a User ID (UID) and a primary Group ID (GID). This identity determines what files and resources you can access.

User Accounts: The /etc/passwd File

Linux stores user information in /etc/passwd, a simple text file where each line represents one user:

alice:x:1001:1001:Alice User,,/home/alice:/bin/bash
root:x:0:0:root:/root:/bin/bash
raquib:x:1000:1000:Raquib,,,/home/raquib:/bin/bash

Each field means:

• username: Your login name (alice, root)
• password: Placeholder x (real hash is in /etc/shadow, hidden from regular users)
• UID: Numeric user ID (0 = root, 1000+ = regular users)
• GID: Primary group ID (usually matches UID in modern systems)
• comment: Real name or description
• home: Home directory path
• shell: Login shell (usually /bin/bash)

Key insight: Linux identifies you by numeric UID internally. The username is just a label—if you rename a user account, all file ownership stays intact because ownership uses the UID, not the name.

Password Security: /etc/shadow

Password hashes aren't stored in /etc/passwd (which is world-readable). Instead, they're in /etc/shadow, readable only by root:

alice:$6$...(hash)...:19000:0:90:7:14:19500

Fields:

• username: Account name
• password hash: Encrypted password
• lastchg: Days since Jan 1, 1970, when password was last changed
• min: Minimum days between password changes (0 = anytime)
• max: Maximum age—password expires after this many days
• warn: Days before expiry to warn user at login
• inactive: Days after expiry before account auto-locks
• expire: Absolute day when account itself expires
• reserved: Usually empty

This separation keeps passwords safe while allowing /etc/passwd to be shared system-wide.

---

The Permission Trinity: Users, Groups, and Others

Every file and directory on Linux has three ownership tiers:

-rw-r----- 1 alice devs file.txt

Breaking down this ls -l output:

Understanding Permission Bits

The 9-character permission string breaks into three groups of three:

rw-  r--  ---
^^^  ^^^  ^^^
|    |    |
|    |    +-- Others (everyone else)
|    +------- Group (members of 'devs')
+------------ User/Owner (alice)

Each group of three represents:

• r (read): Permission to read
• w (write): Permission to modify
• x (execute): Permission to execute (for files) or traverse (for directories)
• - (dash): Permission denied

Permissions on Files vs Directories

The same rwx letters mean different things depending on file type:

Critical rule: To access /home/alice/file.txt, you need x (execute) permission on /, /home, and /home/alice directories—not just on file.txt itself. This is why parent directory permissions matter.

---

Groups: Sharing Access Safely

A group is a named collection of users, defined in /etc/group:

devs:x:1002:alice,bob,carol
docker:x:999:alice,david
sudo:x:27:alice,bob

Fields:

• groupname: Name of the group
• password: Usually x (group passwords are rare; skip this)
• GID: Numeric group ID
• members: Comma-separated list of users in this group

Modern Group Model: User Private Groups

Most Linux distributions use a user private group model:

• When you create user alice, the system automatically creates group alice
• Files alice creates default to owner alice, group alice
• This prevents accidental group permission leaks

Special Groups Worth Knowing

Some groups grant powerful privileges:

Checking Your Groups

Find which groups you belong to:

# See your UID, primary GID, and all groups
id

# Output example:
# uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(devs),999(docker)

# Just list group names
id -nG

# Check a specific user
id bob
groups bob
getent group devs  # See all members of 'devs' group

---

User and Group Management Commands

Creating Users

Interactive (Debian/Ubuntu recommended):

sudo adduser alice
# Prompts for password, real name, phone, etc.
# Creates home directory automatically

Low-level (works everywhere):

sudo useradd -m -s /bin/bash alice
# -m: create home directory
# -s: set login shell
sudo passwd alice  # Set password

Modifying Users

# Change login name
sudo usermod -l newname alice

# Change home directory (and move it)
sudo usermod -d /home/newhome -m alice

# Change login shell
sudo usermod -s /bin/zsh alice

# Change primary group
sudo usermod -g devs alice

# Add to extra groups (don't remove existing ones)
sudo usermod -a -G devs,sudo alice

# Change UID (careful! See below)
sudo usermod -u 1100 alice

# Lock/unlock account
sudo usermod -L alice    # Lock
sudo usermod -U alice    # Unlock

Creating and Managing Groups

# Create a group
sudo groupadd devs

# Create with specific GID
sudo groupadd -g 2001 devs

# Rename a group
sudo groupmod -n engineers devs

# Change GID
sudo groupmod -g 2100 devs

# Delete group
sudo groupdel devs

Adding/Removing Users from Groups

# Add user to group (permanent)
sudo usermod -a -G devs alice

# Alternative method
sudo gpasswd -a alice devs

# Remove user from group
sudo gpasswd -d alice devs

# On Debian/Ubuntu
sudo deluser alice devs

Deleting Users

# Delete user, keep home directory
sudo userdel alice

# Delete user and home directory
sudo userdel -r alice

# Debian/Ubuntu wrapper
sudo deluser alice
sudo deluser --remove-home alice

---

The UID/GID vs Username Caveat

Here's a subtle but critical detail: file ownership is stored as numeric UID/GID, not usernames.

Scenario 1: Renaming a User

When you rename alice to alicia:

sudo usermod -l alicia alice

The UID stays the same. ls -l will now show alicia as owner, but the file's ownership hasn't changed—it still belongs to UID 1001, which now maps to alicia. This is safe.

Scenario 2: Changing UID

If you change the UID without updating file ownership:

sudo usermod -u 1100 alice

All of alice's old files still belong to UID 1001—which might now map to a different user or no user at all. To fix this, run:

# Change ownership of all alice's old files to new UID
sudo find /home -uid 1001 -exec chown 1100 {} \;

# Or safer:
sudo chown -R 1100:alice /home/alice

Lesson: Name changes are safe. UID/GID changes require chown and chgrp to realign file ownership.

---

Real-World Permission Scenarios

Let's decode actual permission scenarios:

Scenario 1: Readable by Owner and Group

-rw-r----- 1 alice devs file.txt

• Owner (alice): Can read and write
• Group (devs members): Can read only
• Others: No access

Use case: Configuration files shared within a team.

Scenario 2: Directory with Restricted Access

drwx------ 2 raquib raquib dir

• Owner (raquib): Full access (read, write, execute)
• Group: No access
• Others: No access

Even if dir/secrets.txt is world-readable (-rw-rw-rw-), others still can't access it without x on dir.

Scenario 3: Locked File (Root Only)

---------- 1 root root locked.txt

No one has rwx permissions. But root (UID 0) can still read and modify it because root bypasses normal permission checks.

Scenario 4: Executable Script

-rwxr-xr-x 1 alice alice script.sh

• Owner: Can run, read, and edit
• Group: Can run and read (not edit)
• Others: Can run and read

Use case: Shared utility scripts.

---

Processes, Sessions, and Staying Running

When you log in, your shell and its child processes run as your UID with your groups:

$ id
uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(devs)

If you log out normally, your shell receives SIGHUP, and child processes die. But processes can detach:

• nohup: Immune to SIGHUP
• disown: Detach from shell
• screen/tmux: Multiplexer sessions survive logout
• systemd user services: Per-user background services that auto-restart

Modern systems run:

• System systemd (PID 1): Manages system-wide services
• Per-user systemd --user: One instance per logged-in user, managing that user's services and timers

---

Quick Reference: Common Commands

---

Conclusion

Linux's users, groups, and others system is elegant and powerful once you internalize the three-tier model. Remember:

1. Every process runs as one user (UID) with one primary group (GID) and optional secondary groups
2. Every file has an owner (user), a group, and permissions for others
3. Directories need 'x' permission to traverse—parent directory permissions matter
4. Ownership is stored by UID/GID, not username—name changes are safe, UID changes require chown

With this knowledge, you can design secure access controls, troubleshoot permission errors, and manage multi-user systems confidently. Start practicing with id, usermod, and groupadd on your own machine—understanding builds through hands-on exploration.

---

Want to dive deeper? Check out the Linux man pages: man passwd, man group, man usermod, man chmod.