Linux Under the Hood: A Deep Filesystem Investigation
Most Linux users interact with commands. Advanced users interact with systems. The difference is simple: advanced users understand that Linux is a file-driven operating system where nearly everything is exposed, inspectable, and controllable through the filesystem.
This exploration goes deeper — not just what exists, but how it works internally and why it was designed this way.
1. /etc — Declarative System Design (Not Just Config Files)
What it really is: /etc is not just a config folder—it's a declarative interface to system behavior.
How it works internally:
Programs read these files at runtime or startup. For example:
/etc/nsswitch.conf defines how user lookups happen (files, LDAP, DNS). /etc/hosts overrides DNS before network queries. /etc/fstab defines how filesystems mount during boot
Why Linux chose this model:
Instead of embedding behavior in compiled code, Linux externalizes it into text files.
Problem it solves:
i. Easy automation (edit files instead of recompiling)
ii. Debugging without special tools
iii. Predictable behavior
Deep insight: Linux follows a “configuration as truth” model — not registry-based like Windows. This makes systems reproducible (think DevOps, containers, infra-as-code).
2. DNS Resolution Stack — More Than /etc/resolv.conf
What most people think: DNS = /etc/resolv.conf
Reality (multi-layer resolution pipeline):
i. Application calls getaddrinfo()
ii. Glibc checks /etc/nsswitch.conf
iii. Resolution order may be
hosts: files, DNS
iv. /etc/hosts checked first,
v. Then /etc/resolv.conf used for DNS servers.
vi. Query sent via system resolver
Modern twist:
On many systems, /etc/resolv.conf is managed by:
i. systemd-resolved
ii. NetworkManager
It may even be a symlink, not a real file.
Problem it solves:
Flexible name resolution across:
i. Local overrides
ii. Network DNS
iii. Enterprise systems (LDAP, mDNS)
Deep insight:
DNS resolution is pluggable, not fixed. You can redefine how your system resolves names without changing applications.
3. /proc — Kernel Introspection via Virtual Filesystem
What it is:
A memory-backed virtual filesystem created by the kernel.
How it works internally:
i. No actual disk storage
ii. Files are generated dynamically on read
iii. Each read triggers kernel functions
Example:
i. /proc/cpuinfo → kernel queries CPU data /proc//maps → memory layout of a process
Process deep dive: Inside /proc//:
fd/ → file descriptors (actual open files) exe → symlink to running binary cmdline → how the process was started status → memory, threads, privileges
Problem it solves:
Real-time observability without specialized APIs Debugging at OS level
Deep insight: Linux exposes the kernel as a queryable interface through files, not opaque system calls. Tools like top, ps, and htop are just reading /proc.
4. /sys — Structured Hardware Control (Kernel Object Model)
Difference from /proc:
i. /proc = process + system state
ii. /sys = device + kernel object model
What it is:
A representation of the Linux kernel’s device tree and driver model.
Example structure:
/sys/class/net/eth0/ /sys/block/sda/ /sys/devices/
How it works:
Each file maps to kernel attributes. Writing to files can change kernel behavior
Example:
i.echo 1 > /sys/class/leds/.../brightness
Problem it solves:
Unified interface for:
i. Drivers,
ii. Devices,
iii. Hardware configuration
Deep insight:
Linux treats hardware interaction as file I/O, making scripting and automation trivial.
5. /dev — Device Abstraction Layer
What it really represents: An interface between user space ↔ kernel drivers
Types of devices:
i. Block devices → disks (/dev/sda)
ii. Character devices → keyboard, terminal
iii. Pseudo devices → /dev/null, /dev/zero, /dev/random
How it works internally:
i. Managed dynamically by udev
ii. Device nodes map to kernel driver handlers
Critical concept:
Major & Minor numbers
Major → identifies driver
Minor → identifies device instance
Problem it solves:
Standardized device communication Simplifies hardware access
Deep insight:
Linux doesn’t treat hardware specially — it normalizes everything into file operations, which is why pipelines and redirection work everywhere.
6. /var/log — Observability and Forensics Layer
What it is:
Persistent system event tracking.
How it works:
i. Logs generated by kernel + services
ii. Managed by rsyslog or journald
Modern systems:
i. journalctl reads binary logs from journald.
ii. Logs may not always be plain text anymore
Key logs:
i. auth.log → authentication events
ii. syslog → general system logs
iii. dmesg → kernel ring buffer
Problem it solves:
i. Debugging failures
ii. Security auditing
iii. Performance tracking
Deep insight:
Logs are not just records — they are the only historical memory of system behavior. If logs are gone, root cause analysis becomes guesswork.
7. /etc/passwd, /etc/shadow, /etc/group — Identity System
How authentication actually works:
i. /etc/passwd → user metadata
ii. /etc/shadow → hashed passwords
iii. /etc/group → group memberships
Important fields:
username:x:UID:GID:comment:home:shell
Security model:
i. Password hashes moved to /etc/shadow.
ii. Only the root can read the shadow file
Problem it solves:
i. Separation of identity and secrets
ii. Multi-user access control
Deep insight:
Linux identity is file-based, not service-based. This is why systems can work even without a running authentication daemon.
8. /etc/systemd — Init System as Dependency Graph
What it is:
Configuration for systemd, the modern init system.
How it works:
Services defined as .service files Dependencies form a directed graph, not linear boot
Example:
After=network.target
Requires=network.service
Why this matters:
i. Parallel startup
ii. Faster boot time
iii. Better fault handling
Problem it solves:
i. Managing complex service dependencies
Deep insight:
Linux boot is no longer sequential — it’s event-driven and dependency-based, like a distributed system.
9. /proc/net — Networking Without Tools
What it exposes:
i. Routing tables
ii. Active connections
iii. Interface stats
Example:
i. /proc/net/tcp
ii. /proc/net/route
How it works:
Kernel networking stack exports internal tables as readable files.
Problem it solves:
Direct inspection without tools like netstat
Deep insight:
Networking isn’t hidden — Linux exposes the entire stack for inspection. Tools are just convenience layers.
10.Permissions & Ownership — Minimal Yet Powerful Security Model
Core structure:
rwx | user / group / others
How it works internally:
Each file has:
UID (owner)
GID (group)
Mode bits
Advanced layer:
SUID, SGID
Sticky bit
ACLs (Access Control Lists)
Problem it solves:
i. Secure multi-user environment
Deep insight:
Linux security is simple by design, but extensible when needed. Most real-world vulnerabilities come from misconfigured permissions, not system flaws.
🔥 Final Perspective
After this deep dive, one pattern becomes clear:
Linux is built on 3 core principles:
i. Everything is a file
ii. Expose internal state
iii. Favor transparency over abstraction