Skip to main content

Linux Permissions & Users

Understanding Linux permissions is crucial for security and system administration. Think of permissions like the keys and locks in an office building: every room (file) has a lock, every person (user) carries certain keys, and the building manager (root) has the master key. Getting this wrong means either locking yourself out or leaving the vault wide open.

User Management

Every process in Linux runs as a specific user. This determines what files it can read, write, and execute. There is no such thing as an “anonymous” action in Linux — everything traces back to a user.

Users and Groups

Groups let you manage permissions for multiple users at once. Instead of granting file access to ten developers individually, you add them all to a dev group and grant access to the group.
Always use -aG (append to groups), not just -G. Running usermod -G developers username without the -a flag removes the user from every other group, potentially locking them out of sudo access.

File Permissions

Every file and directory in Linux has three sets of permissions for three audiences: the owner, the group, and everyone else.

The Permission Model

Each permission has a numeric value. You add them up to set permissions:
Practical rule of thumb: Scripts and binaries get 755 (everyone can run, only owner can edit). Config files get 644 (everyone can read, only owner can edit). Secrets and keys get 600 (owner only). Private directories get 700.

Changing Ownership

Special Permissions

Beyond the basic rwx, Linux has three special permission bits that come up in interviews and production troubleshooting. Think of these as special-purpose locks with unusual properties — they solve problems that regular permissions cannot.
Security warning about SUID: SUID binaries are a common attack vector. If an attacker can overwrite a SUID-root binary (or find a vulnerability in one), they get root access. Audit your SUID files periodically with find / -type f -perm -u+s 2>/dev/null and remove SUID from any binary that does not need it. Never set SUID on shell scripts — it is a well-known security hole because the script can be manipulated between the kernel checking SUID and the interpreter executing it.

Sudo and Root Access

The root user (UID 0) can do anything on the system — bypass all permission checks, kill any process, read any file. This power is dangerous. sudo lets you run individual commands as root without staying logged in as root.

Sudoers Configuration

Production tip: Grant the minimum sudo access needed. NOPASSWD: ALL on a service account is a security incident waiting to happen. Scope it to specific commands like /bin/systemctl restart myapp.

Common Permission Scenarios

Scenario 1: Shared Project Directory

Scenario 2: Securing SSH Keys

Scenario 3: Web Server Files


Key Takeaways

  • Every file has an owner, a group, and permissions for owner/group/others
  • Use chmod for permissions, chown for ownership
  • Numeric mode (755, 644) sets all permissions at once; symbolic mode (u+x) modifies specific bits
  • sudo grants temporary root access for individual commands — prefer it over logging in as root
  • Special bits (SUID, SGID, sticky) solve real problems but require careful use
  • Always use usermod -aG (with the -a flag) to add users to groups

Next: Linux Process Management →