containers
RFC: introduce live mounting
Marked as RFC because this is not at all production ready and the whole concept might be questionable. Feedback (especially about the overall design) is very welcome.
In flatpak we would like to be able to make a host subtree visible to some bwrap'ed processes some time after they have already been started (https://github.com/flatpak/xdg-desktop-portal/issues/200).
This patch introduces the '--live-mount-fd FD' option. The process calling bwrap can pass a FD this way and write pairs of directories to it which will be interpreted as source and destionation of a bind mount operation.
To make this work in bwrap we make /newroot a shared mount and clone off into a new mount namespace for what eventually becomes the container, make /newroot a slave mount in this new mount namespace and continue on normally with unmounting /oldroot and pivioting to /newroot. The original process now still has /oldroot and /newroot and changes in /newroot propagate to the container's mount namespace.
Can one of the admins verify this patch? I understand the following commands:
-
bot, add author to whitelist -
bot, test pull request -
bot, test pull request once
I didn't look at the code, but in general I'm very nervous about retaining any kind of permissions in bwrap after having spawned the child and in particular while taking input from the user.
There are two main risks, first of all in the setuid mode we risk having some way for the user that started bwrap to attack the remaining root helper process and in doing so get increased privileges.
The second risk is one of container breakout, if we in any way leak a reference to the helper into the sandbox it can be attacked. Like you could ptrace the helper or something.
Its possible that the second can be made safe, by ensuring that the namespaces are completely separated, not leaking any fds, etc. However, the first is imho a non-stopper, as the risks involved (full root access) is much greater.
:umbrella: The latest upstream changes (presumably #386) made this pull request unmergeable. Please resolve the merge conflicts.