From 33d17b2b92b87b27842767df14c362e13023f735 Mon Sep 17 00:00:00 2001 From: Daan De Meyer Date: Fri, 31 Jul 2026 19:58:50 +0200 Subject: [PATCH] sandbox: Don't create shared propagation peer group Shared mount propagation always causes extremely hard to debug bugs. For example, if I do the following mounts /my/rootfs/path => /buildroot /dev => /buildroot/dev /my/rootfs/path => /buildroot/a/b/c Then what will happen with shared mount propagation on / is that when /dev is mounted to /buildroot/dev, it will be propagated back to /my/rootfs/path/dev, and so as well to /buildroot/a/b/c/dev. Then, when /buildroot/a/b/c/dev is unmounted during teardown, /buildroot/dev will also be unmounted, causing mayhem during cleanup. Let's stick to slave propagation so the behavior is actually sane. The only reason we were doing shared is because nspawn was doing it and the only reason nspawn does it is because some bit of systemd's service namespacing happens to depend on it. With shared mount propagation, Signed-off-by: Daan De Meyer --- mkosi/sandbox.py | 5 ----- 1 file changed, 5 deletions(-) diff --git a/mkosi/sandbox.py b/mkosi/sandbox.py index 4959d9248..76a5af874 100755 --- a/mkosi/sandbox.py +++ b/mkosi/sandbox.py @@ -1690,11 +1690,6 @@ def enter(argv: list[str]) -> list[str]: # As documented in the pivot_root() man page, this will unmount the old rootfs. umount2(".", MNT_DETACH) - # Avoid surprises by making sure the sandbox's mount propagation is shared. This doesn't - # actually mean mounts get propagated into the host. Instead, a new mount propagation peer - # group is set up. - mount("", ".", "", MS_SHARED | MS_REC, "") - if chdir: os.chdir(chdir) -- 2.47.3