bubblewrap should fall back to MS_MOVE if pivot_root() fails #592
Comments
What's your use-case for using bubblewrap in an initramfs? During early boot, at which point you are root and already have every privilege that could possibly exist, a tool that is not constrained by being designed for use by unprivileged users might be more successful. |
I often boot straight into an initramfs as it is faster and easier than building and booting into a full disk image.
Sure, but the tool I maintain (https://github.com/systemd/mkosi) does have those constraints and is specifically intended to be used by unprivileged users. It just so happens that I also want to be able to run it from an initramfs. Supporting an alternative to bubblewrap in mkosi just to be able to run mkosi from an initramfs seems like a huge amount of work compared to making sure bubblewrap can operate in an initramfs. |
|
Related: #595 |
|
Workaround: |
|
sorry for the tangential comment, but that workaround is very helpful, thanks for sharing @DaanDeMeyer . I came across this issue in googling a pivot_root error from crun running from initramfs and that fixes it. Are there any caveats to using that approach? I don't fully understand/appreciate what it is doing. My notes on using it to run a container in a VM from initramfs are here. Now that I say that, kata must deal with the same thing since that is also from initramfs, |
I haven't encountered any caveats yet but I don't use this to run a container runtime so I wouldn't know. |
|
Could you explain why this works? My vague understanding was that |
|
|
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount and make that a new root to work around this problem. This hack is fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. There are some minor issues with this trick (the initramfs sticks around at the top of the mount tree, but is completely masked) but they don't really matter for containers. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount of / and make that your new root to work around this problem. This does use chroot(2), but this is only done temporarily to set current->fs->root to the new mount. Once pivot_root(2) finishes, the chroot(2) and / are gone. Variants of this hack are fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. This is a slightly modified version that uses the container rootfs as the temporary spot for the / clone -- this allows runc to continue working with read-only image-based OS images. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount of / and make that your new root to work around this problem. This does use chroot(2), but this is only done temporarily to set current->fs->root to the new mount. Once pivot_root(2) finishes, the chroot(2) and / are gone. Variants of this hack are fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. This is a slightly modified version that uses the container rootfs as the temporary spot for the / clone -- this allows runc to continue working with read-only image-based OS images. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount of / and make that your new root to work around this problem. This does use chroot(2), but this is only done temporarily to set current->fs->root to the new mount. Once pivot_root(2) finishes, the chroot(2) and / are gone. Variants of this hack are fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. This is a slightly modified version that uses the container rootfs as the temporary spot for the / clone -- this allows runc to continue working with read-only image-based OS images. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount of / and make that your new root to work around this problem. This does use chroot(2), but this is only done temporarily to set current->fs->root to the new mount. Once pivot_root(2) finishes, the chroot(2) and / are gone. Variants of this hack are fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. This is a slightly modified version that uses the container rootfs as the temporary spot for the / clone -- this allows runc to continue working with read-only image-based OS images. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount of / and make that your new root to work around this problem. This does use chroot(2), but this is only done temporarily to set current->fs->root to the new mount. Once pivot_root(2) finishes, the chroot(2) and / are gone. Variants of this hack are fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. This is a slightly modified version that uses the container rootfs as the temporary spot for the / clone -- this allows runc to continue working with read-only image-based OS images. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
While pivot_root(2) normally refuses to pivot a mount if you are running with / as initramfs (because initramfs doesn't have a parent mount), you can create a bind-mount of / and make that your new root to work around this problem. This does use chroot(2), but this is only done temporarily to set current->fs->root to the new mount. Once pivot_root(2) finishes, the chroot(2) and / are gone. Variants of this hack are fairly well known and is used all over the place (see [1,2]) but until now we have forced users to have a far less secure configuration with --no-pivot. This is a slightly modified version that uses the container rootfs as the temporary spot for the / clone -- this allows runc to continue working with read-only image-based OS images. [1]: containers/bubblewrap#592 (comment) [2]: https://aconz2.github.io/2024/07/29/container-from-initramfs.html Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
pivot_root()does not work in the initramfs. As a fallback,MS_MOVEcan be used together withchroot()to mimickpivot_root()somewhat. bubblewrap should use this fallback ifpivot_root()is not possible (e.g. when running bubblewrap from the initramfs) so that bubblewrap can be used from the initramfs.Currently running bubblewrap from the initramfs fails with
bwrap: pivot_root: Invalid argumentThe text was updated successfully, but these errors were encountered: