Linux File System Hunting
Hunting in the Dark: What I Discovered Deep Inside the Linux File System
There is a famous mantra in the Unix/Linux world: "Everything is a file." When you first learn Linux, you memorize commands: ls, cd, ip route, ps. But commands are just illusions—they are merely translators. Under the hood, Linux manages hardware, networking, running applications, and security entirely through text files and directory structures.
I decided to stop relying on commands and instead act as a system investigator, hunting through the raw file system to see how Linux works. Here are 7 fascinating discoveries from deep inside the Linux hierarchy.
How /etc controls system behavior
The Configuration Brain of Linux
The /etc directory stores many of the system’s configuration files. It controls how the machine behaves rather than containing the actual programs themselves.
Common files here include:
/etc/hostname
/etc/hosts
/etc/resolv.conf
/etc/passwd
/etc/group
Why it exists
Linux separates software binaries from machine-specific configuration. This allows the same software to be installed on many systems while each system behaves differently based on its own config files.
What problem it solves
It solves the problem of customizing system behavior without modifying program code.
Insight I learned
I learned that Linux is surprisingly readable. Many important settings are stored as plain text, which makes the system easier to inspect, understand, and troubleshoot.
Example:
cat /etc/hostname
cat /etc/hosts
Where DNS configuration lives and how it works
/etc/resolv.conf — Where DNS Configuration Lives
What it does
This file tells Linux which DNS servers to use when converting names like google.com into IP addresses.
Why it exists
Humans use domain names, but networks work using IP addresses. The system needs a clear place to define where name resolution requests should go.
What problem it solves
It solves the problem of domain name resolution.
Without DNS, users would need to remember IP addresses instead of website names.
Insight I learned
A broken DNS configuration can make a machine feel “offline” even when the internet connection is actually working. That means networking problems are not always connection problems — sometimes they are just name resolution problems.
#The companion file /etc/resolv.conf had just one line:
nameserver 8.8.8.8 # Google DNS no fallback configured
Routing table inspection through system files
/etc/hosts — A Small File That Can Override the Internet
What it does
/etc/hosts maps hostnames directly to IP addresses locally on the machine.
Why it exists
Before DNS became standard, systems used local host mapping files. Even today, this file is useful for local testing and overrides.
What problem it solves
It solves problems like:
local development
hostname overrides
internal network mapping
quick testing without DNS dependency
Insight I learned
This file gave me an important realization: the local machine can override wider network behavior. A tiny file on one system can change how that machine resolves a domain, even if DNS says something else.
That is powerful.
Network interface configuration locations
Routing and network state can be inspected from the system itself
I also explored how Linux stores networking information beyond simple IP settings.
Interesting places include:
/proc/net/route
/proc/net/dev
/sys/class/net/
These exist because the kernel needs to expose network interface and routing information to the rest of the system.
They solve the problem of visibility into network behavior:
which interface exists
how much traffic passed through it
where packets should be sent
what the default route is
The most interesting thing I learned is that routing is not abstract magic. Linux exposes it clearly enough that tools can read and display it. This helped me connect commands like ip route to the underlying system data.
Example:
cat /proc/net/route
cat /proc/net/dev
ls /sys/class/net
# /proc/net/route (raw — columns in hex, little-endian)
Iface Destination Gateway Flags Mask
c72...-v CE000415 00000000 0001 7FFFFFFF
c72...-v 00000000 CF000415 0003 00000000
System logs and what insights they provide
/var/log — System Logs Tell the Story of the Machine
What it does
Linux stores many logs in /var/log, while modern systems may also use journalctl with systemd.
Common log areas include:
/var/log/syslog
/var/log/auth.log
/var/log/kern.log
Why it exists
Systems need a historical record of what happened — logins, errors, service starts, crashes, warnings, and more.
What problem it solves
It solves the problem of post-event investigation and troubleshooting.
Insight I learned
Logs are not only for errors. They also reveal normal system behavior. By reading logs, you can understand the machine’s story: what started, what failed, who logged in, and what changed.
That makes logs one of the most valuable places for real system exploration.
Example:
ls /var/log
sudo tail -n 50 /var/log/syslog
journalctl -xe
User management files
/etc/passwd, /etc/shadow, and /etc/group — Linux User Management Is File-Based
What they do
These files manage users and groups:
/etc/passwd stores user account details
/etc/shadow stores password hashes
/etc/group stores group information
Why they exist
Linux was designed as a multi-user operating system. It needs a structured way to manage identities, authentication, and access control.
What problem they solve
They solve the problem of managing multiple users securely on the same system.
Insight I learned
What stood out to me was the separation of user identity from password security:
user information can be visible
password hashes remain protected
That design is smart because it allows the system to identify users without exposing sensitive authentication data.
Example:
cat /etc/passwd
cat /etc/group
sudo cat /etc/shadow
Permission structures and security implications
Linux Permissions — Security Starts at the File Level
What they do
Every file and directory in Linux has permissions for:
owner
group
others
These permissions define who can read, write, or execute a file.
Why they exist
Linux must control access in a multi-user environment so that one user or process cannot freely interfere with everything else.
What problem they solve
They solve the problem of access control and file-level security.
Insight I learned
I learned that permissions are not an extra security layer added later. They are part of Linux’s core design.
I also learned something subtle but important: directory permissions behave differently from file permissions.
For directories:
read = view names
write = modify entries
execute = enter/traverse
That changed how I think about directory security.
That changed how I think about directory security.
Example:
ls -l
ls -ld /etc /root /home
The Decoupled Passwords: /etc/passwd vs /etc/shadow
The Finding: Investigating how Linux handles user accounts and authentication security.
What it does: /etc/passwd lists every user, their user ID (UID), and their home directory. /etc/shadow contains the actual hashed passwords.
Why it exists: Historically, everything was in passwd. But passwd must be readable by all users so apps know who is who.
Problem it solves: Keeping passwords in a world-readable file was a massive security flaw. Linux solved this by splitting the data. passwd remains readable, but the passwords were moved to shadow, which is locked down strictly to the root user.
The Insight: Looking at my user entry in /etc/passwd, the password field literally just says x. This x tells the system, "Go look in the shadow file." Checking the shadow file (as root), I saw my password hash started with $6$. This tiny prefix is a system flag indicating the hash uses SHA-512, an incredibly secure encryption standard.
# /etc/passwd — the x is a placeholder meaning "look in shadow"
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
# /etc/shadow permissions
-rw-r----- 1 root shadow 609 Apr 11 00:13 /etc/shadow
# Only root + shadow group can read it (mode 640)
```
Process-related filesystem entries inside /proc
The Matrix is Real: The Virtual World of /proc
The Finding: I explored /proc and specifically looked at /proc/cpuinfo and /proc/1/cmdline.
What it does: /proc is a "pseudo-filesystem." The files inside it do not actually exist on your hard drive. They are illusions created by the Linux kernel, residing entirely in RAM.
Why it exists: It acts as a real-time window into the kernel.
Problem it solves: Instead of forcing developers to write complex API calls to ask the kernel about system health or running apps, Linux just formats the answers as text files you can read.
The Insight: I looked inside /proc/1/cmdline. Process ID 1 is the very first process that starts when Linux boots (usually systemd). Reading this file showed me the exact boot parameters the kernel used to wake the system up. It felt like looking at the system's DNA.
Example:
cat /proc/cpuinfo
cat /proc/meminfo
cat /proc/1/status
Device handling inside /dev
The Black Hole and The Dice Roller: /dev/null and /dev/urandom
The Finding: Exploring the /dev directory, which houses "device files."
What it does: /dev/null is a file that immediately destroys any data written to it. /dev/urandom is a file that spits out endless, random gibberish when read.
Why it exists: They represent hardware concepts (a void, and an entropy generator) abstracted as files.
Problem it solves: When a script outputs massive, annoying errors, you need a place to throw them away (/dev/null). When SSH or a web server needs to generate a secure encryption key, it needs a source of absolute randomness (/dev/urandom).
The Insight: I realized these aren't files; they are gateways to kernel subroutines. Redirecting a massive 5GB log stream directly into /dev/null consumed zero disk space. It was instantly vaporized.
Examples:
/dev/sda
/dev/null
/dev/zero
/dev/random
/dev/tty
# /dev listing (character devices shown with 'c')
crw-rw-rw- 1 root root 1, 7 /dev/full # Always returns ENOSPC on write
crw-rw-rw- 1 root root 1, 3 /dev/null # Discards all written data
crw-rw-rw- 1 root root 1, 8 /dev/random # Cryptographic entropy (blocking)
crw-rw-rw- 1 root root 1, 9 /dev/urandom # Non-blocking random
crw-rw-rw- 1 root root 1, 5 /dev/zero # Infinite stream of zero bytes
crw-rw-rw- 1 root root 10,229 /dev/fuse # FUSE filesystem interface
lrwxrwxrwx /dev/stdin -> /proc/self/fd/0
lrwxrwxrwx /dev/stdout -> /proc/self/fd/1
lrwxrwxrwx /dev/stderr -> /proc/self/fd/2
Boot-related configs inside /boot
/boot reminds us that Linux startup begins long before login
The /boot directory contains files needed during system startup, such as:
kernel images
initramfs/initrd files
bootloader-related data
This directory exists because the machine needs a reliable place to load the kernel and early boot resources before the full filesystem is active.
It solves the problem of startup sequencing. The system cannot mount everything and launch services unless the kernel itself is loaded first.
The insight I learned here is that Linux boot is layered:
firmware starts
bootloader loads kernel
kernel initializes
init system starts services
user space becomes ready
So /boot is small, but it is the doorway to the entire operating system.
Service configs inside /systemd or /etc/systemd
systemd service files show how Linux starts and manages services
On many modern Linux systems, service behavior is controlled by systemd.
Useful places include:
/etc/systemd/system
/lib/systemd/system
/usr/lib/systemd/system
These folders contain unit files that define how services start, stop, restart, and depend on each other.
Why do they exist? Because modern systems need a structured, automatable way to manage background services such as networking, SSH, cron, databases, and web servers.
This solves the problem of service orchestration.
My key insight was that booting a Linux machine is not just “start everything.” It is a dependency-driven process. Service files define order, restart behavior, targets, and execution details. That makes Linux startup much more organized than I had assumed.
Example:
systemctl list-unit-files
cat /etc/systemd/system/*.service
Environment configuration behavior
Environment settings quietly shape user experience
Another subtle discovery was environment configuration.
Files like:
/etc/environment
/etc/profile
~/.bashrc
~/.profile
help define variables such as PATH, language, editor preferences, and shell behavior.
These files exist because users and programs need a flexible way to define their working environment.
They solve the problem of repeatability and customization. Instead of manually setting values every session, Linux can load them automatically.
The interesting insight here is that environment configuration feels invisible until it breaks. If PATH is wrong, commands stop being found. If shell init files are misconfigured, the terminal behaves strangely. That taught me that many “small” config files have system-wide consequences.
What this exploration taught me overall
The biggest lesson from this Linux hunting exercise is that Linux is remarkably transparent. Many operating systems hide internal behavior behind graphical tools or opaque system databases. Linux often exposes core behavior directly through files, directories, and text-based configuration.
That design solves several important problems at once:
easier debugging
better automation
scriptability
auditability
fine-grained control
It also changes the way I think about the file system. It is not just a place to store documents. In Linux, the file system is also an interface to the kernel, devices, configuration, services, and system state.
After this exploration, I understand why Linux is so popular in servers, DevOps, cybersecurity, and system administration. It rewards curiosity. The more you inspect its files, the more the operating system starts to explain itself.
Conclusion: The Grand Illusion
Before this hunt, I viewed Linux as a collection of magical commands. Now, I realize that commands are just polite requests made to text files.
From the hardware abstraction in /dev to the real-time kernel memory in /proc, to the security rules in /etc, Linux isn't a black box. It is an incredibly transparent, beautifully organized filing cabinet. If you know which drawer to open, there are no secrets.
