Re: [PATCH 0/2] mount: add OPEN_TREE_NAMESPACE

On Mon, Jan 19, 2026 at 10:56=E2=80=AFAM Askar Safin <[email protected]>=
 wrote:
>
> Christian Brauner <[email protected]>:
> > Extend open_tree() with a new OPEN_TREE_NAMESPACE flag. Similar to
> > OPEN_TREE_CLONE only the indicated mount tree is copied. Instead of
> > returning a file descriptor referring to that mount tree
> > OPEN_TREE_NAMESPACE will cause open_tree() to return a file descriptor
> > to a new mount namespace. In that new mount namespace the copied mount
> > tree has been mounted on top of a copy of the real rootfs.
>
> I want to point at security benefits of this.
>
> [[ TL;DR: [1] and [2] are very big changes to how mount namespaces work.
> I like them, and I think they should get wider exposure. ]]
>
> If this patchset ([1]) and [2] both land (they are both in "next" now and
> likely will be submitted to mainline soon) and "nullfs_rootfs" is passed =
on
> command line, then mount namespace created by open_tree(OPEN_TREE_NAMESPA=
CE) will
> usually contain exactly 2 mounts: nullfs and whatever was passed to
> open_tree(OPEN_TREE_NAMESPACE).
>
> This means that even if attacker somehow is able to unmount its root and
> get access to underlying mounts, then the only underlying thing they will
> get is nullfs.
>
> Also this means that other mounts are not only hidden in new namespace, t=
hey
> are fully absent. This prevents attacks discussed here: [3], [4].
>
> Also this means that (assuming we have both [1] and [2] and "nullfs_rootf=
s"
> is passed), there is no anymore hidden writable mount shared by all conta=
iners,
> potentially available to attackers. This is concern raised in [5]:
>
> > You want rootfs to be a NULLFS instead of ramfs. You don't seem to want=
 it to
> > actually _be_ a filesystem. Even with your "fix", containers could comm=
unicate
> > with each _other_ through it if it becomes accessible. If a container c=
an get
> > access to an empty initramfs and write into it, it can ask/answer the q=
uestion
> > "Are there any other containers on this machine running stux24" and the=
n coordinate.

I think this new OPEN_TREE_NAMESPACE is nifty, but I don't think the
path that gives it sensible behavior should be conditional like this.
Either make it *always* mount on top of nullfs (regardless of boot
options) or find some way to have it actually be the root.  I assume
the latter is challenging for some reason.

--Andy