Writing Outside the Working Directory When the Sandbox Says No

What "inside the working directory" means

Confining writes to a working directory sounds like one problem with one solution, but it splits into two very different implementations. The weak version checks paths: the harness inspects the string a program wants to write to, verifies it starts with the allowed prefix, and passes it through. The strong version confines at the filesystem level: the process runs in a mount namespace or a chroot whose root is the working directory, so paths outside it do not exist to be written to — or a MAC policy denies the syscalls outright.

The weak version fails in the ways string checks always fail. Paths can be normalised ('a/../b' resolves to 'b'), symlinks can point out of the tree while their textual path stays inside, relative paths depend on the current directory, and filesystem features like bind mounts or hard links let the same inode appear under multiple names. Each of those is a way for "the string says inside" and "the write lands outside" to both be true.

The strong version does not consult the string at all. If the namespace root is the working directory, there is no name for anything outside it; if MAC denies writes beyond a label, the denial happens in the kernel regardless of path games. The difference between the two is the difference between validating a request and making the request impossible.