Failfs is a pretty cool pseudo-filesystem where every path lookup fails. So if yu place a statically-linked process into failfs with ONLY pre-allocated file-descriptors at process birth, close down unneeded sockets and enforce a default-deny firewall discipline, compromised applications are effectively isolated and unable to access local files or spawn shells during an exploit. An attacker can NOT move adjacently from the exploited process to other parts of the system because to do so they'll need to navigate from root and that would fail since yu set root as failfs and you've got yourself a pure, isolated data-processing pipe that can only interact via the exact file descriptors it was given!!

Unfortunately, yu can't use dynamically-linked apps anyway since failfs would break absolute path resolution loading system libraries.

EDIT:: But I guess yu could put a statically linked app on the socket, wrap it in failfs and gave it proxy requests to a dynamically-linked app process if your app must use something like python.

For sandboxing: https://hackaday.com/2026/08/07/this-filesystem-is-born-to-f...

A process which is chrooted into failfs cannot open new files. It is limited to the set of filesystem file descriptors it already has open (presumably set up before the chroot or inherited into the process from some container runtime).

I'd love to have one that randomly fails, so we could debug e.g. databases and other apps that are supposed to be resilient. I'd call it "havocfs". Doesn't corrupt data, just randomly fails reads/writes/etc. Some software is supposed to handle that gracefully. Would be a great test tool...

It looks like it's useful for sandboxing by preventing any possible filesystem movement.

https://docs.kernel.org/next/filesystems/failfs.html

Reading the description, looks like a stricter chroot for purely-network applications, maybe?