Re: [RFC] Null Namespaces
From: Christian Brauner <brauner@kernel.org>
Date: 2026-07-24 08:04:29
Also in:
linux-arch, linux-fsdevel, lkml
quoted
quoted
For my FD_FAILFS_ROOT proposal it would be enough if we make failfs SB_KERNMOUNT which means it's logically distinct from every mount namespace. I think that might be the right thing to do. I need to spend one or more brain cycles on this though.I had to take a long drive on Sunday and I kept thinking about both FD_NULLFS_ROOT and FD_FAILFS_ROOT and ofc there are some things to consider/discuss. I think the straightforward solution to FD_NULLFS_ROOT would be to just: - make it always available - refer to the caller's mount namespace nullfs - work with fchroot()/fchdir() So I considered two chroot() use-cases for the sake of simplicity: (1) You want to isolate yourself for the sake of lookup (2) You want to isolate yourself to assemble a "private mount tree" but not really be in a separate namespace (very odd use-case... but it helps to make a point). The problem with this approach is that everyone who chroots into the nullfs root would suffer from the problem that any mount on top of it is still visible. So that kinda makes it pointless for both (1) and (2). Also all mounts that someone else would do would also be visible allowing multiple chroot()ers to affect each others state. That also would somewhat defeat the purpose of the chroot(). So I'm not convinced this is what we should do.After some contemplation and a long place flight: are we talking about nullfs or failfs? Because I would expect that it's entirely
nullfs
impossible to mount anything on top of failfs. So failfs would be useless for #2 but would still solve #1.
Yes, failfs can't be mounted on at all.