Linux for Backend Engineers

• Part 1: The Foundation
• Part 2: Files, Filesystems, and Permissions ← current
• Part 3: Processes and Threads
• Part 4: Memory Management
• Part 5: Signals and Communication
• Part 6: IPC, Networking, and Containers

6. Everything Is a File: The Linux I/O Model

Linux uses a clever trick; it pretends that almost everything is a file. Your documents, folders, keyboard, hard drive, and even information about your CPU appear as files in one giant tree starting at / (the root).

Because everything is a file, you can use the same simple commands (cat, ls, grep) to explore hardware, processes, and network connections.

Try This: Everything Is a File

# Inspect your CPU model
cat /proc/cpuinfo | grep "model name" | head -1
 
# Read current memory usage
cat /proc/meminfo | head -5
 
# Inspect metadata for your active shell process ($$ returns current PID)
cat /proc/$$/status | head -10
 
# Write output directly to the void
echo "disappear" > /dev/null

6.1 File Types

In Linux, everything is a file, but there are different types:

🎯 Backend Context (Node.js): When inspecting file metadata using fs.stat(path), the resulting Stats object provides methods like stats.isFile(), stats.isDirectory(), stats.isSymbolicLink(), and stats.isSocket() to check these types programmatically.

6.2 Filesystem Hierarchy Standard (FHS)

Unlike Windows (C:, D:), Linux has a single unified tree starting at the root directory: /. Every file, directory, and mounted storage device lives somewhere under /.

💡 Pro Tip: If you ever get lost exploring the filesystem, run man hier in your terminal to read the official documentation on the layout.

7. Inodes: The Real Identity of a File

A filename is just a label. The real file is an inode, a data structure containing:

• Data blocks (the actual content)
• Inode (metadata: size, permissions, timestamps, pointers to data blocks)
• Directory entry (maps a filename to an inode number)

Directory entry:  "report.txt"  → Inode #49201
Directory entry:  "copy.txt"    → Inode #49201   (hard link)

Hard Links vs. Symbolic Links

• Hard link: Another directory entry pointing to the same inode. Deleting the original does not delete the data while any link remains.
• Symbolic Link (Symlink): Creates a special file that contains the text path to another file. If the original file moves or is deleted, the symlink breaks.

# Create a test environment
cd ~/linux-practice
 
echo "original text" > original.txt
ln original.txt hard.txt       # Hard link (Shares same Inode)
ln -s original.txt soft.txt    # Soft link (Points to path)
 
# Check Inode numbers (-i flag)
ls -li original.txt hard.txt soft.txt
 
# Remove original file and check access
rm original.txt
cat hard.txt   # Still works! Inode count is > 0
cat soft.txt   # Error: No such file or directory (Broken link)

🎯 Backend Context (Node.js):

1. fs.stat() resolves symbolic links and returns stats for the target file. To inspect a symlink itself, use fs.lstat().
2. Deleting a file in Node.js (fs.unlink()) decrements the link count on the target Inode. The data blocks are only physically freed when the total link count reaches 0 and no active processes hold an open file descriptor to it.

8. The Linux Security Model: Permissions

          - rwx r-- r--  1 alice staff  1024 May  1 12:00 file.txt
          │ │││ │││ │││
          │ │││ │││ └┴┴─ Others
          │ │││ └┴┴───── Group
          │ └┴┴───────── User (Owner)
          └───────────── File Type
 
File Type:
-  Regular file
d  Directory
l  Symbolic link
 
Permissions:
r = Read
w = Write
x = Execute
- = No permission

Every file has:

• Owner (user)
• Group
• Permissions for user, group, and others: read (r), write (w), execute (x).

Example: -rw-r--r-- 1 alice staff 1024 May 1 12:00 file.txt

• Owner alice can read and write.
• Group staff can read.
• Others can read.

🎯 Backend Context (Node.js): Whenever your Node process attempts an I/O operation, the OS kernel evaluates the process's effective User ID (UID) and Group ID (GID) against the file's permissions. If access is denied, Node raises an EACCES error. Permissions can be updated programmatically via fs.chmod() and fs.chown().

8.1 Octal Permission Calculations

While symbolic string notation (rwxr-xr-x) is easy to read, permissions in shell scripts and backend systems are often calculated as 3-digit octal numbers.

Each permission corresponds to a bit value:

To determine the octal digit for a user category, simply add up the active permission values:

Read (4) + Write (2) + Execute (1) = 7
Read (4) + Write (2) + None (0)    = 6
Read (4) + None (0)  + Execute (1) = 5
Read (4) + None (0)  + None (0)    = 4
None (0) + None (0)  + None (0)    = 0

755
│││
││└── Others  →  Read (4) + Execute (1)             = 5 (r-x)
│└─── Group   →  Read (4) + Execute (1)             = 5 (r-x)
└──── Owner   →  Read (4) + Write (2) + Execute (1) = 7 (rwx)

Common Permission Patterns

🛠️ Try It Yourself: Shell Usage

Change file modes in the terminal using chmod with octal values:

# Make a deployment script executable
chmod 755 deploy.sh
 
# Restrict an environment file to owner read/write only
chmod 600 .env
 
# Inspect numeric permissions with stat
stat -c "%a %n" deploy.sh .env
# Output:
# 755 deploy.sh
# 600 .env

🎯 Backend Context (Node.js): Permissions can be set programmatically using fs.chmod(). Always use JavaScript's octal literal prefix (0o) when passing permission modes:

fs.chmod("file.txt", 0o600, (err) => {
  if (err) throw err;
  console.log("Permissions updated to 600 (rw-------)");
});