When you ran cd ../../.. inside the jail and checked your location, why couldn’t you exit? How does the kernel manipulate path resolution for a chroot-ed process?

When we execute cd ../../.. inside a standard chroot jail, we cannot exit because the kernel actively prevents the process from traversing past its designated root directory during path resolution. To the process, the jail’s root directory is the absolute global root (/). When a process executes a command like cd .., it tells the operating system to move up one level in the directory hierarchy. However, in a virtual file tree, the root directory (/) has a unique property: it is its own parent. The Kernel Manipulates Path Resolution When the chroot() system call is successfully invoked, the kernel modifies the calling process’s fs_struct->root pointer, shifting it from the host’s actual global root directory to the target “jail” directory. And whenever a process requests a file operation (like open(), chdir(), or stat()), the Virtual Filesystem (VFS) layer inside the kernel performs a step-by-step evaluation called a Path Walk (follow_dotdot() loop).

What happens if you try to run commands like nano, python3, or grep inside your jail? Explain why they fail, even if they are installed on your host OS.

If we try to run commands like nano, python3, or grep inside a newly created, basic chroot jail, they will fail immediately. Usually a generic error like: bash: nano: command not found or chroot: failed to run command ‘/bin/grep’: No such file or directory. These commands fail because a chroot jail alters the process’s view of the filesystem root. Even if these utilities are installed on the host operating system, the isolated process cannot see or access any files outside of the jail directory.