Update bwrap.xml: Indicate potential problem forking mountspaces may cause.

[ghost]

The only indication that this may occur is the timing of lsof return - with every instance of bubblewrap closed, return was a bit faster. Problem referenced: https://forums.gentoo.org/viewtopic-t-1116050-start-0.html

When a mount namespace is forked from its parent, it inherits all existing mounts. When you ran umount, you only unmounted in the namespace where you ran that. The device remains mounted in any other mount namespaces where it was mounted, preventing you from closing the device.

Nothing indicated why a mapped device was busy when attempting to close.

[rusty-snake]

Actually bwrap should not keep devices busy because it uses slave mount propagation. See also #522.

Do you use OpenRC or runit or something like that?

[ghost]

Actually bwrap should not keep devices busy because it uses slave mount propagation. See also #522.

Do you use OpenRC or runit or something like that?

I do. Is that somehow related to the problem?

[rusty-snake]

Could be because man 7 mount_namespaces says

The propagation type assigned to a new mount depends on the
propagation type of the parent mount. If the mount has a parent
(i.e., it is a non-root mount point) and the propagation type of
the parent is MS_SHARED, then the propagation type of the new
mount is also MS_SHARED. Otherwise, the propagation type of the
new mount is MS_PRIVATE.

Notwithstanding the fact that the default propagation type for
new mount is in many cases MS_PRIVATE, MS_SHARED is typically
more useful. For this reason, systemd(1) automatically remounts
all mounts as MS_SHARED on system startup. Thus, on most modern
systems, the default propagation type is in practice MS_SHARED.

[rusty-snake]

What does grep "/ / " /proc/self/mountinfo | cut -d" " -f7-8¹ show when you execute it instead of bubblewrap?

_{¹This it not the correct way to parse mountinfo but should work here.}

[ghost]

grep "/ / " /proc/self/mountinfo | cut -d" " -f7-8

"- ext4"

without the cut:

27 1 254:2 / / rw,relatime - ext4 /dev/mapper/vg_pool-rootfs rw

[rusty-snake]

Yeah, for me (Fedora 37) it is shared:1 -. So you're root is mounted with private mount propagation causing all this.

If you want you can try what happens after you run mount --make-shared /. But I'm not entirely sure what happens if you change the mount propagation of / after early boot or if it crashes the system.

[ghost]

I see, thanks. Are there any security implications for making mount point non-private? Does software running in bubblewrap gain more attack surface?

[rusty-snake]

Does software running in bubblewrap gain more attack surface?

Since bubblewrap always unshare the mount namespaces and makes all mountpoints slaves, nothing changes for the code running in bubblewrap. But see below.

Are there any security implications for making mount point non-private?

Depends on your thread models (the ultimate answer to every question starting with " Are there any security implications").

For / is shared propagation the default on 95% of all Linux systems. I don't think that there is any real risk. Some very esoteric thread models relaying on monkeys on the Mars selling dubious phone contacts to you might have one.

There is however a implication with removable media (actually mounting in general but after system start you usually only mount removable media) and sandboxing. I did not check how bubblewrap behaves here (because heavily depends on the command line options you use) but systemd.exec explicitly states:

In particular, note that mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace, i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated below a path marked with ReadOnlyPaths=! Restricting access with these options hence does not extend to submounts of a directory that are created later on. This means the lock-down offered by that setting is not complete, and does not offer full protection.

[ghost]

That was informative.