# Explain Linux Command Execution, Filesystems, and Isolation Walk through the operating-system mechanisms behind common Linux commands and isolation choices. Keep the explanation concrete: identify user-space work, system calls, kernel objects, permissions, and failure paths instead of treating each command as a black box. ### Clarifying Questions to Ask - Which shell and executable-search rules should be assumed? - Should the discussion focus on Linux specifically or portable Unix behavior? - Are namespaces and cgroups in scope for containers? - How deep should packet-routing and device-driver details go? ### Part 1: From Shell Input to a Running Command Explain what happens after a user enters an external command. Contrast that path with a shell builtin such as `cd`. Then explain at a high level how `ls`, `pwd`, `ip`, and legacy interface-inspection tools obtain their results. #### What This Part Should Cover - Parsing, expansion, path lookup, process creation, `exec`, waiting, and exit status - Why a child process cannot change its parent shell's working directory - Directory enumeration and metadata system calls - Working-directory state and kernel networking interfaces ### Part 2: Files, Directories, Permissions, and procfs Explain how a process opens a path, how directories differ from regular files, how user and group permission checks are applied, what major top-level filesystem areas represent, and why `/proc` is not an ordinary disk directory. #### What This Part Should Cover - Path traversal through directory entries to inode-like objects - File descriptors and the open-file-description layer - Directory execute versus read permission and effective credentials - Virtual filesystems and process/kernel views exposed through `/proc` ### Part 3: Containers Versus Virtual Machines Compare containers and virtual machines, including isolation boundary, kernel sharing, startup and resource overhead, operational trade-offs, and cases where each is a better fit. #### What This Part Should Cover - Namespaces, cgroups, capabilities, and shared-kernel risk - Hypervisor and guest-kernel isolation - Image, portability, density, and boot-time trade-offs - A workload-driven choice rather than a universal preference ### What a Strong Answer Covers - A coherent boundary between shell, libraries, kernel, and hardware - Accurate permission and filesystem reasoning - Practical security and operability trade-offs - Recognition that exact implementations vary while core contracts remain ### Follow-up Questions - What changes when a command is connected to a pipeline? - Why can a pathname race occur between checking and opening a file? - What does a container escape mean in a shared-kernel model? - How do user namespaces alter privilege inside a container?