bubblewrap currently uses the traditional mount(2) API for everything. This is not a great interface for container'y use cases.
In particular, the mount(2) API has the problem that it is path-based rather than fd-based, requiring some strange and non-robust code to implement --[ro-]bind-fd (which is necessary for Flatpak and other sandboxing frameworks that operate on attacker-controlled directory hierarchies, which need to use --[ro-]bind-fd to avoid vulnerabilities like CVE-2024-42472 and CVE-2026-34078).
If we use the "new mount APIs", it should be possible to implement --[ro-]bind-fd with open_tree(..., AT_EMPTY_PATH | OPEN_TREE_CLONE | AT_RECURSIVE) followed by mount_setattr() and move_mount(..., MOVE_MOUNT_F_EMPTY_PATH), similar to some of the examples in open_tree(2).
Similarly, --{,dev-,ro-}bind-fd could be implemented in a similar way, but starting from AT_FDCWD and an absolute path, rather than a fd and AT_EMPTY_PATH.
On older kernels, none of this would work (ENOSYS or EINVAL), and we'd have to fall back to the way things are currently done.
#754 should probably be done first - that's a much simpler use of the "new mount APIs".
A possible follow-up would be to increase the minimum kernel version to one that implements all of the necessary syscalls, but (like #754) that would mean abandoning the ability to run bubblewrap (and therefore Flatpak, the Steam Runtime, etc.) on older distros like RHEL 8 and Ubuntu 20.04, which is something we have historically tried hard not to do. If that is done, then I think it should be a separate PR and a separate issue.
[Tracked as steamrt/tasks#1005 elsewhere]
cc @ao2
bubblewrap currently uses the traditional
mount(2)API for everything. This is not a great interface for container'y use cases.In particular, the mount(2) API has the problem that it is path-based rather than fd-based, requiring some strange and non-robust code to implement
--[ro-]bind-fd(which is necessary for Flatpak and other sandboxing frameworks that operate on attacker-controlled directory hierarchies, which need to use--[ro-]bind-fdto avoid vulnerabilities like CVE-2024-42472 and CVE-2026-34078).If we use the "new mount APIs", it should be possible to implement
--[ro-]bind-fdwithopen_tree(..., AT_EMPTY_PATH | OPEN_TREE_CLONE | AT_RECURSIVE)followed bymount_setattr()andmove_mount(..., MOVE_MOUNT_F_EMPTY_PATH), similar to some of the examples in open_tree(2).Similarly,
--{,dev-,ro-}bind-fdcould be implemented in a similar way, but starting fromAT_FDCWDand an absolute path, rather than a fd andAT_EMPTY_PATH.On older kernels, none of this would work (
ENOSYSorEINVAL), and we'd have to fall back to the way things are currently done.#754 should probably be done first - that's a much simpler use of the "new mount APIs".
A possible follow-up would be to increase the minimum kernel version to one that implements all of the necessary syscalls, but (like #754) that would mean abandoning the ability to run bubblewrap (and therefore Flatpak, the Steam Runtime, etc.) on older distros like RHEL 8 and Ubuntu 20.04, which is something we have historically tried hard not to do. If that is done, then I think it should be a separate PR and a separate issue.
[Tracked as steamrt/tasks#1005 elsewhere]
cc @ao2