15 min·Foundation

A container starts with files

Build a tiny root filesystem and make it the root of a real Linux process.

An image is a filesystem

Before namespaces or daemons, a container image is a collection of files. This tiny image contains BusyBox, a shell, and an /etc/release file. It has no kernel: the running machine provides that.

FROM minimal-rootfs
COPY busybox /bin/busybox
COPY release /etc/release
CMD ["/bin/sh"]

Change a process's view

Linux resolves absolute paths from a process's root directory. chroot changes that root. Our prepared image lives at /tmp/lab-root. Inside it, /etc/release should refer to the image's file, and the outer /work directory should be out of sight.

Your change

The launcher accepts a root directory and a command. Right now it ignores the root. Replace its last line so the command runs through /bin/sh inside the supplied root. Run displays the image's release file; Test also checks a different image and visibility outside the root.

Your goal

Make launch.sh run its command inside the supplied root filesystem using chroot.

What the tests observe

Image files become /
Outer /work is outside the root
One launcher works with two images

Need a nudge?

Hint 1

BusyBox provides a chroot command. Its shape is: chroot NEWROOT COMMAND ARGUMENTS…

Hint 2

The shell you execute must exist inside the new root. The prepared image includes /bin/sh.

Hint 3

Pass the command string as one argument to /bin/sh -c. Preserve the quotes around both shell variables.

What happens inside Linux

Only pathname lookup changed. The process still shares the machine's kernel, hostname, process namespace, and resources. A privileged process can escape a careless chroot; it is one filesystem primitive, not a complete security boundary.

Optional account sync. Exercises work without an account.

Containers