4.3 The Filesystem Hierarchy Standard

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

4.3 The Filesystem Hierarchy Standard

Key Takeaways Explain This Topic AI

The Filesystem Hierarchy Standard (FHS) defines the purpose of each top-level directory so files land in predictable places across distributions

/etc holds host-specific configuration, /var holds variable data such as logs and caches, and /boot holds the kernel, initramfs, and bootloader files

/proc and /sys are virtual filesystems created in memory by the kernel: /proc exposes processes and kernel state, /sys exposes devices and kernel objects

Kali is FHS-compliant, and on modern Debian/Kali the /usr merge makes /bin, /sbin, /lib, and /lib64 symlinks into their /usr counterparts

• /root is the private home directory of the root user and is deliberately separate from /home
• Last updated: July 2026

One Tree, Predictable Places

Linux has no drive letters. Every storage device is mounted somewhere inside a single directory tree whose top is the root directory, / . The Filesystem Hierarchy Standard (FHS) defines what each top-level directory is for, so that an administrator moving between Debian, Kali, Fedora, or a server appliance finds configuration, logs, and binaries in the same places. Kali is explicitly FHS-compliant, and the KLCP exam tests the purpose of individual directories directly.

The Core Directories

• Directory Purpose
• /bin Essential user command binaries needed in single-user or rescue mode (e.g. ls , cp , cat )
• /sbin Essential system administration binaries, traditionally for root ( fdisk , ip , fsck )

/etc Host-specific, static configuration files ( /etc/passwd , /etc/fstab , /etc/ssh/sshd_config ) — no binaries

• /var Variable data that changes while the system runs: logs ( /var/log ), caches, spool, databases
• /tmp Temporary files; world-writable with the sticky bit (1777) and typically cleared at boot

/usr The FHS secondary hierarchy — shareable, read-only data (the name is historically short for "user"; "Unix System Resources" is a later backronym): the bulk of installed software — /usr/bin , /usr/sbin , /usr/lib , plus shared data in /usr/share ; historically mountable read-only and shareable between machines

/home Home directories for regular users, e.g. /home/kali

/root Home directory of the root user, kept outside /home so root can log in even if /home is a separate, unavailable mount

/boot Static boot files: the kernel image ( vmlinuz ), the initial RAM disk ( initrd.img ), and the GRUB bootloader configuration

• /dev Device files representing hardware, populated dynamically by udev
• /proc Virtual filesystem exposing processes and kernel state ( /proc/cpuinfo , /proc/meminfo , /proc/<pid>/ )
• /sys sysfs : virtual filesystem exposing devices, drivers, and kernel objects for udev and tuning
• /opt Optional, self-contained third-party application bundles (many security tools drop here)
• /srv Data served by the system itself (web roots, FTP content) when you run it as a server
• /run Volatile runtime data (PID files, sockets) kept in RAM since the last boot
• /media , /mnt Standard mount points: /media for auto-mounted removable media, /mnt for temporary manual mounts
• Virtual Filesystems Deserve Special Attention

/proc and /sys exist only in memory — the kernel fabricates their contents on read, and writing to some entries tunes the kernel live (for example echo 1 > /proc/sys/net/ipv4/ip_forward enables IP forwarding, a classic pivoting step). They consume no disk space, which you can confirm with du : the exam likes asking why /proc reports strange sizes.

The /usr Merge in Modern Debian and Kali

Historically, /bin , /sbin , /lib , and /lib64 held the bare minimum needed to boot before /usr (possibly on another disk) was mounted. Modern systems assemble an initramfs (initial RAM filesystem) early in boot, so that split no longer serves a purpose. Current Debian — and therefore current Kali — performs the /usr merge : those four top-level directories are now symbolic links into /usr : $ ls -ld /bin /sbin /lib /lib64

• lrwxrwxrwx 1 root root 7 /bin -> usr/bin
• lrwxrwxrwx 1 root root 7 /lib -> usr/lib
• lrwxrwxrwx 1 root root 9 /lib64 -> usr/lib64
• lrwxrwxrwx 1 root root 8 /sbin -> usr/sbin

Practical consequences for the exam: a tool documented as living in /bin is physically stored in /usr/bin , both paths resolve to the same file, and scripts with a #!/bin/sh shebang keep working untouched. The old distinction between /bin and /usr/bin is effectively gone on a fresh Kali install.

Using the Layout in Practice

Knowing the FHS tells you where to look before you ever run a search. Hunting a service's settings? Start in /etc . Suspect a rootkit hid files? Check world-writable /tmp and /dev/shm . Need the kernel or want to back up boot configuration? Everything static is in /boot . Disk filling up? /var/log and /var/cache grow continuously, while /home holds user data. Triaging an odd process? Read /proc/<pid>/cmdline and /proc/<pid>/exe . Because Kali follows the FHS, lessons learned on any compliant distribution transfer directly — and because the exam is written from the Kali Linux Revealed book, directory-purpose matching questions (for example, 'where do variable data and logs live?' → /var ) are common.

Looking Inside /var and /usr

Two directories reward a closer look because the exam tests their subdivisions. Under /var , the split is by lifecycle: /var/log holds log files (rotated by logrotate so disks do not fill), /var/cache holds data programs can regenerate or re-download if deleted, /var/lib holds persistent application state such as the dpkg database in /var/lib/dpkg that APT consults for every install, /var/tmp holds temporary files that must survive reboots (unlike /tmp ), and /var/spool queues jobs such as mail and print tasks. Under /usr , the split is by content type: /usr/bin and /usr/sbin hold executables, /usr/lib holds libraries and architecture-dependent files, /usr/share holds architecture-independent data such as documentation, icons, and wordlists — on Kali this includes the famous /usr/share/wordlists , which ships rockyou.txt.gz (run sudo gunzip /usr/share/wordlists/rockyou.txt.gz before first use) — and /usr/local is reserved for software the administrator compiles and installs manually, so package managers never overwrite it. That last point is a favorite exam trap: locally compiled tools belong in /usr/local , not /opt (which is for self-contained third-party bundles) and not directly in /usr/bin (which the package manager owns).