Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com