Part 2: Navigating Filesystems & Access Controls (Permissions & Users)

Welcome back to the Linux: Master Series Guide. In Part 1, we established a precise mental model of Linux, broke down its architecture layers, and rapidly deployed a workspace.

Now, we shift our focus from setting up the system to effectively living and operating inside it. To manage Linux, you must master two core concepts: The Filesystem Hierarchy (where everything is a rooted tree without drive letters) and Access Controls (how multi-user security is enforced through permissions).

01: The Filesystem Hierarchy

In Linux, "everything is a file." There are no drive letters (C:\, D:\). Instead, the filesystem is a single rooted tree, starting at the root directory: /.

Understanding a handful of top-level directories accounts for almost everything you will touch as an engineer. A common mental default for address ranges still maps useful patterns, but you must prioritize these core paths:

Core System Directories

These directories are fundamental to system operations:

System Configuration, User, and Volatile Data

Virtual Filesystems (The Kernel Window)

These are not real directories on disk—they are virtual windows generated on-the-fly by the kernel to expose system state:

02: Users, Groups, and Identification

Linux is a multi-user OS from the ground up, and user management is central to keeping a system secure. Four system files back this multi-user scheme:

1. /etc/passwd: Account details (User, primary group ID, home directory, login shell).

2. /etc/shadow: Stores encrypted password hashes safely (not readable by normal users).

3. /etc/group: Group definitions (names and member lists).

4. /etc/gshadow: Secure group details (secure group admins).

Everyday Identification Commands

In most enterprise and container environments, you will prioritize key-based authentication for remote access via SSH. Key-based authentication (Ed25519 or RSA) is critical for automation and eliminates brute-force and credential-stuffing attacks.

03: The Access Control Layer (Permissions)

Every file and directory on a Linux system is backed by three access classes: an Owner (User), a Group, and Others.

Each class is assigned three permission bits: Read (r), Write (w), and Execute (x).

Inspect them with ls -l:

ls -l myapp.sh
# -rwxr-xr-x 1 user group 1234 Mar 28 10:00 myapp.sh

Modes and Octal Values

Permissions can be set using symbolic mode (u+x) or numeric (octal) mode. In octal, permission bits are summed per class:

• Read (r) = 4

• Write (w) = 2

• Execute (x) = 1

Example Octal Setups:

• chmod 755 [file]: Full access for owner, read/execute for group/others (standard for executables).

• chmod 644 [file]: Read/write for owner, read-only for group/others (standard for config files).

• chmod 700 [file]: Full access for owner, zero access for everyone else.
  

Special Permission Bits

While rwx is standard, three special bits exist to solve specific operational challenges:

04: Advanced Access Control Lists (ACLs)

Managing standard permissions is foundational. However, standard rwx bits only cover one owner and one group.

To resolve complex access matrices (granting named users or additional named groups access without changing standard permissions), prioritize Filesystem Access Control Lists (ACLs):

# View active ACLs
getfacl backup.db

# Grant user 'postgres' RWX access to backup.db
sudo setfacl -m u:postgres:rwx backup.db

# Grant group 'admins' RX access to /var/data
sudo setfacl -m g:admins:rx /var/data/

Mastering the filesystem hierarchy, multi-user identification, and permissions resolution ensures the system—and the applications running on top of it—operate securely and consistently.