<- Back
Comments (24)
- 0x2b9fd814feb0Zones from Solaris is a nice name.NetBSD's jail feature is based on kauth, a decent designed capabilities system, informed by an Apple technical paper. Having jails backed by kauth puts NetBSD's well above FreeBSD's, if NetBSD can reach feature parity. The earlier implementation struggled with a networking feature that NetBSD did not have.Also, this work is made with AI:"For context: this is my first serious work inside the NetBSD kernel. I am not an experienced NetBSD kernel developer. To better understand complex code paths and trade-offs, I use AI-based tools for analysis and occasionally for draft implementations. However, everything that goes into my working tree is manually reviewed, adjusted, or discarded by me. I only integrate changes that I believe are technically sound and that I can explain and defend, and I am working towards a clean and auditable tree structure."https://mail-index.netbsd.org/tech-kern/2026/03/01/msg030854...
- lateraluxIt’s awesome to see Unix descendants still alive and active. NetBSD has been doing some really cool stuff lately, like PVH boot support. Kudos to the SmolBSD team, a really fun project that made NetBSD PVH boot support, allowing it to boot a microVM on QEMU in ~10 ms https://smolbsd.org
- ggmI'll make the same comment I did on the other post about this. Either document how it differs from FreeBSD jails or give it some other name. Anything else is asking for confusion.
- yjftsjthsd-hI'm a little surprised; I guess I would have assumed that if netbsd got jails they'd be an outgrowth of rump kernels with improved security properties. No big deal, just unexpected.> Jails share the host network stack by design.> This keeps routing, firewalling, and interface management simple on the host.> Listening ports can be reserved per jail.> Port ownership is enforced by the kernel, preventing accidental conflicts while preserving a straightforward host-centric network model.It's perfectly reasonable to have a different approach, but on Linux I'll say I really prefer that each container has its own view of ports; it is specifically useful that I can run multiple copies of the same app and they can all bind :8000 or whatever and that just works.
- arcade79Uh; not the same as FreeBSD jails? But name conflict? That's just silly.
- mpetermaHi, Matthias here - the person currently working on Jails for NetBSD, if one can call it that.First of all, thank you for the lively discussion and all the feedback. I’ve been following the thread for a few days and I genuinely appreciate the input. Earlier today I also received a thoughtful email with some suggestions, which motivated me to respond here publicly as well.To give a bit of background: the idea was indeed inspired by FreeBSD. I’m a long-time admirer of FreeBSD and have worked with it for many years. In my day job I mostly deal with Linux, Kubernetes, etc., while NetBSD has become the interesting counterpoint for me in my personal projects.My original goal was actually to reproduce something quite close to FreeBSD jails. That’s also why you currently see aliases like jls and jexec in /etc/profile. But while learning the NetBSD internals and experimenting with prototypes, I realized that some of the defining properties of FreeBSD jails - particularly network isolation and strict resource controls in hot kernel paths - would require moving outside the relatively well-defined and safer territory of the secmodel framework. For a first kernel project, that started to feel like a risky direction.At the same time, NetBSD already has a very elegant and robust answer for strong isolation of networking and resources like CPU and RAM: Xen. From a security perspective, that happens at a level where these concerns are naturally handled.Because of that, the project gradually shifted. What currently exists (secmodel_jail) focuses more on controlled process isolation within the host rather than full virtualization-style containment. In parallel I’m already thinking about a concept where Xen VMs and these lighter-weight “jails” could be provisioned through a unified control plane, making the distinction transparent at the operational level.Regarding the name: I completely understand the confusion.When you picture a jail in the strict sense - a fully isolated cell with solid walls, a tiny window, and a food slot in the door - the current prototype is not quite that. What I built so far is closer to a cage: it prevents escape, but you can still reach through the bars. In practical terms, that means certain host resources remain shared, while the security model prevents destructive interactions (for example via signals).That analogy is simplified, but it captures the spirit.Because of this mismatch, I’m not opposed to renaming the project at this stage. Someone suggested “cages”, which actually fits the current design quite well. I’m also open to other ideas and might run a small poll once things settle a bit.In any case, I just wanted to let you know that I’ve read the comments and appreciate the discussion. Feedback - critical or supportive - is very welcome, especially while the design is still evolving.Thanks for the thoughtful conversation.
- DeathArrowIt would have been more interesting have they released something compatible with Open Container Initiative. Most people use Docker containers and having Docker compatible containers would have helped with improved adoption of BSDs.