First time hearing about failfs. Does it have a niche use case or is it just for testing?

saint-evan 4 hours ago | parent | next [-]

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.

▲

wpyoga 4 hours ago | parent | next [-]

Is it possible to load the dynamic libraries before fork()ing and somehow prevent the path lookup and library loading? This will open up new possibilities for hardened security models.

▲

saint-evan 4 hours ago | parent [-]

That's a fun idea but take python (very familiar)... It's very deeply dynamic and even if yu run imports at the top of your code yu still have many large libs with lazy code execution baked deep inside their internal functions so that assumes yu actually know what code paths the application will hit later. More importantly this goes in the opposite direction of Python's lazy imports thingy.. basically you've got a bomb and yu wouldn't wanna do that. Also, imagine the startup time for large apps. I'd just put a statically-linked binary in front and proxy back to the dynamically-linked process if I can't rewrite the main app in something like Go or Rust.

	▲	ffsm8 2 hours ago \| parent [-]
		You explicitly stated as such, I just want to emphasize it again: it only breaks dynamically linked libraries, which - from a stability point of view - is an antipattern anyway. Almost always youre better off producing a bundle which has everything (excluding the runtime) included... Or just use better languages which categorically don't even have this scenario, eg golang, Java, rust, etc pp

▲

dhx 2 hours ago | parent | prev | next [-]

Is it different from using seccomp with SECCOMP_RET_ERRNO and return code of EOPNOTSUPP for all filesystem syscalls?

▲

jack_pp 4 hours ago | parent | prev | next [-]

idk if it's just me but deliberately using "yu" instead of "you" is annoying and makes me not really take whatever you say seriously

	▲	Nexxxeh 2 hours ago \| parent \| next [-]
		Yeah, it feels "not ND friendly" too. Totally breaks my reading flow. I am the person addressed when someone says "you", not "yu". Why is that person changing how I'm addressed? It's also confusing because it feels initially like it's some new Linux command or user, like "su".
	▲	tgv 2 hours ago \| parent \| prev [-]
		Lil' TAFKAP, the modern version of Saint Exupery.

▲

pandemic_region 4 hours ago | parent | prev [-]

Sorry man I've been out of the loop with the hip crowd for a good while, but is "yu" now a thing like "thru" once was?

▲

saint-evan 4 hours ago | parent [-]

no biggie... I just like how 'yu' looks. It's an aesthetic.

▲

pandemic_region 4 hours ago | parent [-]

Thanks, at first I thought it was the name of another tool or library ;)

	▲	asimovDev 3 hours ago \| parent [-]
		I immediately parsed it as some CLI i don't know about as well

▲

rwmj 4 hours ago | parent | prev | next [-]

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).

▲

nesarkvechnep 21 minutes ago | parent | next [-]

They’ll do everything but adopt Capsicum. Shame.

▲

shevy-java 4 hours ago | parent | prev | next [-]

So basically more fine tuned jail controls.

I'd love if chrooting would become easier. In particular a requirement to have bash or a specific shell is annoying; imo a simple REPL should suffice already there. I wrote one that works years ago, need to look into what is all needed for a chroot (I always used bash for this but I'd also want to change to my own shell eventually).

	▲	rwmj 4 hours ago \| parent [-]
		We wanted capabilities[1]. Instead we get this over-complicated series of system calls with no design consistency that you have to use very carefully, else they can be bypassed (see the list of caveats on the failfs page). [1] https://en.wikipedia.org/wiki/Capability-based_security

▲

judetechdevs 4 hours ago | parent | prev [-]

[dead]

▲

zero_k 4 hours ago | parent | prev | next [-]

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...

	▲	rwmj 3 hours ago \| parent [-]
		Devices rather than filesystems, but .. https://libguestfs.org/nbdkit-error-filter.1.html & https://libguestfs.org/nbdkit-evil-filter.1.html

▲

rustyhancock 5 hours ago | parent | prev | next [-]

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

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

▲

5 hours ago | parent | prev | next [-]

[deleted]

▲

degamad 5 hours ago | parent | prev [-]

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