Phase 1: Foundations

File system hierarchy, permissions & ownership

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine a huge, amazing library, but instead of books, it's full of all the information and programs your computer needs to work. Just like a library that would be chaos if books were just dumped anywhere, computers need a super organized system. That's what we call the "file system hierarchy." It’s like a grand plan that tells you exactly where to find the "how-to" guides for running programs, the "rulebooks" for how programs should behave, the "diary" of everything that’s happened (we call those "logs"), and even a "scratchpad" area for temporary notes. Knowing this map means you can instantly go to the right shelf or section to find what you need, saving tons of time.

Now, in our library, not everyone can do everything, right? If you check out a book, it's yours for a while, and you're the "owner." You can read it, keep it safe, and eventually return it. Other people in the library might just be able to look at it on the shelf, or maybe only the librarians can change its catalog entry. On a computer, every file and folder has an "owner" – usually the person or program that created it. It also belongs to a "group," which is like a special club, say "Librarians" or "Book Club Members," who might have extra privileges.

Then come the "permissions," which are like little sticky notes on each book or shelf telling everyone what they can and cannot do. There are three main things: you can "read" (look at) something, you can "write" (change or add to) something, and if it's a program, you can "execute" (run) it. So, a library rulebook might be readable by everyone, but only the head librarian can write (change) it. A rare, old book might only be readable by a specific group of researchers and not allowed to leave the building.

So, when you learn about how these computer "libraries" are organized and who can do what with which files, you become like the head librarian or the best library detective! You’ll instinctively know where to find the right "rulebook" if a program isn't working right, or where to check the "diary" of events to see what went wrong. You'll also know how to make sure that only the right people can change important "rulebooks," keeping everything super secure and running smoothly. This means you can keep computer systems organized, safe, and efficient, just like a perfectly managed library.

As an SRE, navigating Linux file systems efficiently is foundational. The File System Hierarchy Standard (FHS) provides a consistent, standardized structure for where files and directories are located. This isn't just academic; it's a critical tool for your daily work. You'll learn that system binaries live in /bin or /usr/bin, configuration files are typically in /etc, logs are in /var/log, and temporary files go to /tmp. Understanding this structure means you'll instinctively know where to look for service configurations, application logs, or executables when troubleshooting, automating tasks, or deploying new services, saving valuable time during critical incidents.

Beyond just where files are, understanding who can access them and what they can do is paramount for security and operational stability. This is where permissions and ownership come in. Every file and directory in Linux has an owner (a user) and a primary group. Permissions define the actions (read, write, execute) that the owner, the owner's group, and everyone else ("other") can perform on that file or directory. For an SRE, correctly setting these is non-negotiable. You'll ensure critical configuration files are only modifiable by specific system users, prevent unauthorized access to sensitive data like private keys, and manage service accounts to only have the minimal necessary permissions (the principle of least privilege).

Misconfigured permissions are a common source of security vulnerabilities and application failures. You'll frequently use commands like ls -l to inspect current permissions and ownership, chmod to change permissions (e.g., making a script executable or securing a config file), and chown to change the owner or group of a file. Mastering these basic commands allows you to securely deploy applications, manage service accounts, and ensure the integrity of your infrastructure, directly impacting the reliability and security of the systems you maintain.

Key Takeaways

  • The File System Hierarchy Standard (FHS) provides a consistent structure; learn key directories like /etc, /var/log, and /bin to quickly find files.
  • Permissions (read, write, execute) control actions on files/directories, while ownership (user, group, other) defines who has those permissions.
  • Correct permissions are crucial for system security, preventing unauthorized access to sensitive data and critical system files.
  • The Principle of Least Privilege: services and users should only have the minimal permissions required to function.
  • ls -l, chmod, and chown are essential commands for viewing and managing file system permissions and ownership.

Code Example

bash
# Create a dummy file
touch important_config.txt

echo "--- Default permissions (your user:group) ---"
ls -l important_config.txt

# Permissions are displayed as -rwxrwxrwx or drwxrwxrwx (file/directory, user, group, other)
# The default is often rw-r--r-- (644) for files or rwxr-xr-x (755) for directories

echo "\n# Change permissions to owner read/write, group read-only, others no access (640)"
chmod 640 important_config.txt
ls -l important_config.txt

echo "\n# Make the file executable for the owner only (adds 'x' or becomes 740)"
chmod u+x important_config.txt
ls -l important_config.txt

# To change ownership (requires sudo, replacing 'nginx' and 'dev_team' with real system users/groups)
# sudo chown nginx:dev_team important_config.txt
# ls -l important_config.txt

How this code works

The code illustrates the fundamental concepts of viewing and modifying file permissions and ownership within a Linux system. It begins by creating a simple placeholder file using touch important_config.txt. Immediately following, ls -l important_config.txt is executed to reveal the file's detailed attributes, crucially including its default permissions. A key subtle point for beginners is understanding that these initial permissions, often rw-r--r-- (644) for files, are not fixed; they are determined by the system's umask setting, which ensures new files have sensible defaults upon creation.

The script then uses the chmod command to alter these permissions. chmod 640 important_config.txt applies a numeric permission set, granting read/write to the owner, read-only to the group, and no access to others. Subsequently, chmod u+x important_config.txt demonstrates a symbolic approach, specifically adding execute permissions for the owner. This makes the file executable without affecting other permissions. The commented-out sudo chown nginx:dev_team important_config.txt line highlights how to change both the user and group ownership of a file, a powerful operation that requires administrative sudo privileges due to its impact on system security.

Related Articles

Hand-picked reads to go deeper on linux systems.

Back to Site Reliability Engineer Roadmap