Breaking Down Linux File-System

In Linux, **_everything is a file_**—not just text documents or executables, but also devices, network sockets, and even running processes. This idea turns the whole operating system into a giant, interconnected file‑system tree that you can “hunt” through like a detective. In this blog I’ll walk you through 10 meaningful discoveries I made while exploring the Linux file system, focusing on what those files and directories actually do, why they exist, and what interesting insights they reveal. *** ### The brain of the system: `/etc` The `/etc` directory acts as Linux’s configuration brain. It stores almost all system‑wide configuration files, from user accounts (`/etc/passwd`, `/etc/shadow`) to service settings, network parameters, and shell preferences. Why does it exist? Linux is designed to be modular and customizable. Instead of baking settings into the kernel, the system keeps them in human‑readable files under `/etc`, so administrators can tweak behavior without recompiling the OS. What problem it solves: - Centralized configuration: tools like SSH, NTP, and cron all read their config from here, so you can control the whole machine from one place. - Portability: take `/etc` from one server and some settings can be reused on another, as long as the distribution is similar. Interesting insight: Opening `/etc/environment` shows where global environment variables are defined; every user and many system services inherit these values. This means a single file can subtly shape how every process behaves across the system. *** ### DNS and name resolution: `/etc/resolv.conf` and `/etc/hosts` When you type `google.com` into a browser, Linux must translate that into an IP address. The main files that drive this are `/etc/resolv.conf` and `/etc/hosts`. What they do: - `/etc/resolv.conf`: tells the resolver which DNS servers to query and sets search domains. - `/etc/hosts`: maps hostnames to IPs locally, bypassing DNS entirely. Why they exist: Without DNS, you’d have to memorise IP addresses for every service. These files let the system know where to ask for DNS answers and allow quick local overrides for testing or debugging. Example: ```bash $ cat /etc/resolv.conf nameserver 8.8.8.8 nameserver 1.1.1.1 search mycompany.local ``` What problem it solves: - Fault isolation: you can point a test server to a different DNS server by changing just `/etc/resolv.conf`. - Local testing: `/etc/hosts` lets you temporarily route `api.staging.example` to `127.0.0.1` without touching DNS infrastructure. Interesting insight: On some systems `/etc/resolv.conf` is just a symlink to `/run/systemd/resolve/resolv.conf` because `systemd-resolved` manages DNS and caches queries. This reveals how multiple layers of abstraction (service ↔ config ↔ resolver) all converge into a single file that applications read. *** ### Routing tables on disk: `/proc/net/route` and `/etc/iproute2` Routing is the process of deciding which network interface and gateway to use for each packet. Linux exposes its routing table through virtual files under `/proc` and configures higher‑level rules via `/etc/iproute2`. What `/proc/net/route` does: It’s a text representation of the kernel’s routing table, showing destination networks, gateways, and interfaces in hexadecimal. Example: ```bash $ cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric MTU Window IRTT eth0 0000FEA9 00000000 0001 0 0 0 0 0 0 eth0 0200A8C0 00000000 0001 0 0 0 0 0 0 ``` Why `/proc/net/route` exists: The kernel maintains routing data in memory, but users‑pace tools need access. `/proc` exposes this as a file‑like interface so commands like `ip route` and `netstat -r` can read and display it. What problem it solves: - Troubleshooting: if a server can’t reach a remote subnet, inspecting `/proc/net/route` (or `ip route`) can show missing or wrong routes. - Scripting: scripts can parse this file to detect routing changes or validate network config. Interesting insight: Seeing the table in hexadecimal initially looks cryptic, but once you decode the destination and gateway fields (e.g., `0200A8C0` ↔ `192.168.0.2`), you realise it’s literally the kernel’s raw routing logic laid bare as a text file. *** ### Networking interface configuration Network interfaces are controlled by config files and runtime data exposed under the file system. The exact paths differ by distro and network manager, but the idea is the same: configuration files live under `/etc` and running‑state info lives under `/sys` or `/proc`. On many modern systems, NetworkManager writes connection‑specific files such as: ```bash $ ls /etc/NetworkManager/system-connections/ wifi-home.nmconnection server-wired.nmconnection ``` Why these files exist: They persist the settings (SSID, IP mode, gateway, DNS) for each interface so the system doesn’t need to re‑ask for configuration every reboot. What problem they solve: - Automatic re‑connection: after a reboot, the system uses these configs to bring interfaces up correctly. - Multi‑environment: a laptop can have separate configs for home, office, and mobile Hotspot. Interesting insight: Exploring `/sys/class/net/eth0` shows symbolic links and device‑specific files that expose the interface’s driver, speed, and MAC address. This reveals how even hardware is modelled as a file‑system tree, making low‑level inspection surprisingly scriptable. *** ### Logs and digital breadcrumbs: `/var/log` System logs are one of the most powerful “forensic” tools in Linux. The `/var/log` directory houses logs from the kernel, services, and applications, each stored as ordinary text files. Typical files: ```bash $ ls /var/log/ auth.log syslog kern.log nginx/access.log apache2/error.log ``` What they do: - `auth.log` (or `secure` on some distros): records SSH logins, sudo attempts, and other auth events. - `syslog` / `messages`: general system‑wide messages from daemons and the kernel. - Service‑specific logs (e.g., `nginx/*`, `apache2/*`): store web‑server access and errors. Why they exist: Logs answer the “what happened and when?” question. They help debug crashes, track performance issues, and detect security incidents. What problem they solves: - Incident response: after a suspected breach, you can comb through `/var/log/auth.log` to see if there were brute‑force SSH attempts. - Automation: log‑parsing tools read these files and trigger alerts or dashboards. Interesting insight: Reading `/var/log/kern.log` can show exact timestamps of hardware events, such as when a USB device was plugged in or when a disk driver threw an error. This makes `/var/log` feel like a chronological diary of the machine’s entire life. *** ### Users and accounts: `/etc/passwd`, `/etc/shadow`, `/etc/group` User management is surprisingly file‑based. The main files are: - `/etc/passwd`: user names, UIDs, home directories, and default shells (no passwords). - `/etc/shadow`: password hashes, expiry dates, and login restrictions. - `/etc/group`: group definitions and which users belong to them. Example: ```bash $ head -2 /etc/passwd root:x:0:0:root:/root:/bin/bash ritam:x:1000:1000:Ritam,,,:/home/ritam:/bin/zsh ``` Why they exist: Linux follows the principle of “everything is a file.” Instead of a hidden database, user and group data live in plain(ish) text files with strict permissions. What problem they solve: - Fast, portable access: any program that needs UID‑to‑name mapping can open `/etc/passwd` without a database daemon. - Security separation: sensitive password hashes are stored in `/etc/shadow`, which is readable only by root, preventing casual inspection. Interesting insight: Noticing the `x` in `/etc/passwd`’s password field and then finding the actual hash in `/etc/shadow` reveals a clever separation of concerns: one file for public info, another for secret data, all still under `/etc`. *** ### Permissions and the role of `/etc/sudoers` File permissions already give Linux a rich security model, but `/etc/sudoers` adds another layer on top. It defines which users can run which commands as root or other users. Example: ```bash $ grep 'ritam' /etc/sudoers ritam ALL=(ALL:ALL) NOPASSWD:ALL ``` What it does: Each line in `/etc/sudoers` grants a user (or group) permission to run specific commands on specific hosts, sometimes without a password. Why it exists: Direct root logins are risky; sudo allows fine‑grained privilege delegation. An admin can give a developer temporary root‑like access to a web server without handing over the root password. What problem it solves: - Auditability: sudo logs every command to `/var/log/auth.log`, so you can track who did what. - Least privilege: a backup user can run only backup‑related commands, not arbitrary system changes. Interesting insight: Hunting through `/etc/sudoers` and its included snippets (often under `/etc/sudoers.d/`) reveals that even privilege‑escalation logic is ultimately driven by human‑editable text files, not a hidden binary policy engine. *** ### Processes as files: `/proc` The `/proc` filesystem is one of the most fascinating parts of the Linux file system. Each running process gets a directory under `/proc/<PID>`, containing status files, memory maps, and environment variables. Example: ```bash $ ls /proc/1/ cwd environ exe fd/ mem mounts status cmdline ``` What it does: - `status`: basic metadata like memory usage, state, and user ID. - `cmdline`: the command line that started the process. - `fd/`: symbolic links to open file descriptors. - `environ`: environment variables as null‑separated strings. Why `/proc` exists: The kernel exposes process‑level information in a file‑like interface so tools like `ps`, `top`, and `lsof` can read it without needing special syscalls for every piece of data. What problem it solves: - Process inspection: you can literally `cat /proc/$PID/environ` to see which environment variables a service sees. - Forensics: if a process opens suspicious files or sockets, you can inspect `/proc/$PID/fd` and `/proc/$PID/maps` to trace them. Interesting insight: Looking at `/proc/self` (a symlink to the current process’s own directory) makes it feel like each process “lives” in the file system, reading and writing information about itself as if it were any other service talking to a config file. *** ### Device files and `/dev` In Linux, even hardware devices are represented as files under `/dev`. These “device files” let you read from or write to physical devices using the same file‑I/O operations a text program would use. Example: ```bash $ ls -l /dev/sda* brw-rw---- 1 root disk 8, 0 Apr 22 2026 /dev/sda brw-rw---- 1 root disk 8, 1 Apr 22 2026 /dev/sda1 ``` What they do: - `/dev/sda`, `/dev/sda1`, etc.: block device files for disk and its partitions. - `/dev/null`: a sink that discards all data written to it. - `/dev/random`, `/dev/urandom`: provide entropy for random data. Why they exist: The kernel abstracts hardware into a file‑like interface so applications can treat storage, terminals, and other devices uniformly. What problem it solves: - Abstraction: tools like `dd` can back up a disk by literally copying `/dev/sda` to a file, without caring what controller it is. - Security: restrictive permissions on device files prevent random users from directly accessing hardware. Interesting insight: Running `ls -l /dev` and seeing that `/dev/sda` is a “block special” file (`brw-rw----`) shows that even raw disk access is just another file, governed by the same permission model used for regular files and directories. *** ### Boot‑time configuration under `/boot` and `/etc/grub` Booting is orchestrated by files under `/boot` and configuration under `/etc/grub`. These files define which kernel to load, which initramfs to use, and what kernel parameters to pass. Example: ```bash $ ls /boot vmlinuz-6.8.0-10-generic initrd.img-6.8.0-10-generic grub/ ``` What they do: - `vmlinuz-*`: compressed kernel images. - `initrd.img-*`: initial RAM disk used early in boot. - `/boot/grub/grub.cfg` (or `/etc/grub.d/*`): boot‑menu configuration. Why they exist: The bootloader needs to know which kernel and initramfs to load, and the admin needs a way to tweak kernel parameters (e.g., `nomodeset`, `console=ttyS0`). What problem it solves: - Predictable boot: the system can always find the correct kernel and initramfs in `/boot`. - Flexibility: changing `/etc/default/grub` and running `update-grub` generates a new `grub.cfg`, allowing you to experiment with different boot options. Interesting insight: Opening `/boot/grub/grub.cfg` and seeing kernel‑parameter lines like `linux /boot/vmlinuz-6.8.0-10-generic root=UUID=... ro` makes it clear that booting is just another script‑like configuration, defined by plain text that you can read and edit. *** ### Environment and system‑wide configuration Beyond `/etc/environment`, many environment variables and shell settings are defined in files such as `/etc/profile`, `/etc/profile.d/*.sh`, `/etc/bash.bashrc`, and user‑specific `~/.bashrc`, `~/.profile`. Example: ```bash $ cat /etc/profile.d/java.sh export JAVA_HOME=/usr/lib/jvm/java-17-openjdk export PATH=$JAVA_HOME/bin:$PATH ``` What they do: These scripts set environment variables and shell aliases that are inherited by every interactive shell session. Why they exist: To avoid hard‑coding paths and settings into each user’s shell config, distribution maintainers centralize them in `/etc`. What problem it solves: - Consistency: every user on the system gets the same `JAVA_HOME` unless explicitly overridden. - Maintenance: updating one file under `/etc` can propagate a change to all future logins. Interesting insight: Hunting through `/etc/profile.d/*.sh` and comparing them with your own `~/.bashrc` reveals that Linux effectively “assembles” your environment from multiple layers of configuration files, like a stack of configuration cards. *** ### Wrapping up: thinking like a system investigator Exploring the Linux file system beyond basic commands turns you into a kind of system detective. Instead of seeing `/etc`, `/proc`, `/dev`, and `/var/log` as abstract directories, you begin to recognise them as the living, file‑based control plane of the entire OS. Each meaningful discovery—whether it’s decoding a routing table from `/proc/net/route`, reading environment variables from `/etc/environment`, or tracing a suspicious process via `/proc/$PID`—tells you *why* Linux behaves the way it does and *how* you can safely change or debug that behaviour. This “hunting” mindset doesn’t just help with assignments; it trains you to think like the OS itself, which is exactly what you want when you step into roles as a developer, DevOps engineer, or security analyst.