Hacker News Reader

Comment by mdspan | Hacker News Reader

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

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.

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.

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.

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

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?

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

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

I immediately parsed it as some CLI i don't know about as well

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

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

Lil' TAFKAP, the modern version of Saint Exupery.

ah, first sentence I thought yu was a typo. Second sentence I saw it I thought it might be a linux component of sorts. So it's not just a stylistic choice, it's actually harming my comprehension of what they're writing.

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

How is that different from putting an app in a chroot jail or container?

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

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

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

Capability-based security might be the bees knees, but how would one retrofit it into an existing kernel without breaking backwards compatibility?

They’ll do everything but adopt Capsicum. Shame.

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

Devices rather than filesystems, but .. https://libguestfs.org/nbdkit-error-filter.1.html & https://libguestfs.org/nbdkit-evil-filter.1.html

Such a filesystem could be done with FUSE. Devices can be done by Linux itself: https://docs.kernel.org/admin-guide/device-mapper/dm-flakey....

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?

proposed by John Ericsson (Nix core contributor) for the idea of Null namespaces to make namespaces cheaper for when doing finegrained sandboxed builds.

Reply on news.ycombinator.com