This Filesystem Is Born To Fail | Hackaday

Skip to content

Sandboxing a Linux process usually means spending a lot of effort deciding what it isn’t allowed to see. You might put it in a mount namespace, bind-mount a few directories into place, hide some others, add a chroot, and generally construct a carefully restricted version of the filesystem. But a new Linux kernel feature is about to change all of that. Instead of carefully hiding most of the filesystem, why not just take the filesystem away?

That’s essentially the idea behind FailFS, a tiny pseudo-filesystem expected to land in Linux 7.3. As the name suggests, it doesn’t do very much. In fact, that’s the point: every operation that reaches FailFS returns EOPNOTSUPP, meaning "operation not supported."

The interesting bit is what happens when a process uses FailFS as its root or current working directory. At that point, normal pathname lookup essentially ceases to work. Absolute paths fail. Absolute symbolic links fail. Relative paths using the normal current-directory mechanism fail. If the application tries to open /etc/passwd, there simply isn’t a useful /etc to find.

Instead, the process has to start filesystem operations from an explicit file descriptor it already owns. For example, a sandbox manager could open a directory, hand that descriptor to the application, and the application could access files below it using calls such as openat(). Anything not reachable from one of those deliberately supplied descriptors might as well not exist.

Instead of starting with an entire filesystem and constructing rules that say, "not that, not that, not that," you start with nothing and explicitly hand over the pieces the program needs.

There are some interesting consequences. At present, putting a process completely inside FailFS also prevents it from launching ordinary dynamically linked executables. ELF binaries generally specify their dynamic loader using an absolute pathname such as /lib64/ld-linux-x86-64.so.2. Absolute paths don’t work, so neither does the loader.

FailFS also has an interesting sibling called NULLFS, introduced earlier. NULLFS is another deliberately useless filesystem, but it behaves slightly differently: it contains a permanently empty directory and failed lookups return ENOENT, as though the requested file simply doesn’t exist. It was originally introduced to provide an immutable bottom layer beneath the real root filesystem and make operations such as pivot_root() cleaner.

Neither replaces all the other pieces needed for a secure sandbox. Processes still have system calls, networking, IPC, inherited descriptors, and plenty of other ways to cause trouble. But for controlling filesystem access, FailFS has a nice, simple philosophy.

Of course, if your file system is unwritable, that works, too.

3 thoughts on “This Filesystem Is Born To Fail”

Ah, so the Linus finally discovered what microkernels had in one form or another since 1980s. If he spent more time reading books instead of writing code, maybe the Linux Kernel wouldn’t become a bloated abomination it is nowdays.

Report comment

Reply

+1

Report comment

Reply

In the defense of the author, the author was just a young student,

an unlicensed amateur without qualification, who worked on the basis of trial&error.

In addition, this kernal basically started out as a terminal program that went out of control before it became Freax.

– Just like MCP in Tron started out as an chess program (hence its rigidness and unflexibility).

It’s no wonder that it became what it did, thus.

A good foundation is everything in construction.

If someone builds a house on a poor foundation it won’t last, no matter how much fixes came afterwards.

At this point, the best for Linux would be a complete rewrite, maybe.

– That also explains the positive acceptance of Rust an "A.I.".

Maybe it can be done by re-using proven concepts and a sandbox for the device drivers.

After all, the many drivers written by helpers around the world are what makes Linux

run on so much hardware, rather than the monolithic kernal itself.

Without the compatibility to these drivers (at source level at least),

Linux would be more or less meaningless and exchangeable.

It’s like with Windows device drivers. Linux used to rely on wrappers (ndiswrapper etc) to support Windows W-LAN drivers, for example.

This Windows compatibility made it succeed in an increasingly more and more mobile world of computing.

The real tragedy, I think, is however, that no better open source OS came up in the past 30 years or so.

The success of Linux is comparable to that of former Windows 95, maybe.

Both were not really good but about good enough to not make users/developers desperate enough to seek for a better alternative.

That’s how the status quo and stagnation came to be. IMHO.

Report comment

Reply

Leave a ReplyCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment...