4 ms·
It's not even superficial. A chroot is a limiting case of a container that only rebinds the filesystem; or, equally, a container is a chroot that also rebinds t
by scatters 5y ago
It's not even superficial. A chroot is a limiting case of a container that only rebinds the filesystem; or, equally, a container is a chroot that also rebinds the user namespace, process namespace, networking, etc.
- yakubin 5y agoCan you escape from a mount namespace? You can escape from a chroot.
- majewsky 5y agoYou can change into an existing mount namespace, which is what commands like "docker exec" or "machinectl shell" do to execute a command within the mount namespace of an existing container. The container can do the same to escape its mount namespace, but it needs privileges to execute the respective namespace-changing syscall, and it needs to know which namespace to change into. I have an application in a Kubernetes-managed container which needs to do exactly this to access the host system (to open LUKS containers and mount their contents), so I have it run in privileged mode (i.e. with access to all syscalls) and give it the full host filesystem as a bind mount, so it can do: nsenter -m /host/proc/1/ns/mnt mount $DEV $PATH (The actual nsenter invocation is slightly more complicated, but that's the basic gist.) Side-note: Since there will inevitably be a comment along the lines of "but then what do you even need isolation for", I'm very explicitly using Kubernetes as a deployment mechanism only. Other pods within the same Kubernetes are strictly isolated, but this one deliberately runs with practically no isolation. But I still get the consistent environment that Kubernetes provides (rolling upgrades, log shipping, liveness probes, etc.).