Direct sandbox startup fails on merged /usr runner images #22

Problem

start-direct-sandbox.sh bind-mounts individual /usr subdirectories from the sandbox rootfs over the runner container:

mount -o bind,ro "$ROOTFS/usr/sbin" /usr/sbin
mount -o bind,ro "$ROOTFS/usr/lib" /usr/lib
mount -o bind,ro "$ROOTFS/usr/local" /usr/local
mount -o bind,ro "$ROOTFS/usr/bin" /usr/bin

This is fragile when the runner base image uses a merged /usr layout, such as Fedora (which is the dockerfile krun base image) where /usr/sbin can resolve into the same tree as /usr/bin.
In that layout, mounting /usr/sbin separately can hide paths the startup script still needs, in this case mount itself, before the rest of the bind mounts are complete.

Fix

The script assumes /usr/bin, /usr/sbin etc. are independent which breaks with merged /usr layouts. The runner image and the sandbox rootfs can have different /usr structures (One is Fedora the other Debian), so mounting subpaths one-by-one can break the script’s own execution environment.

To fix this we mounted the sandbox rootfs /usr as a single read-only bind mount, after the script has mounted the non-/usr paths it needs:

mount -o bind,ro "$ROOTFS/sandbox_api" /sandbox_api || {
    echo "FATAL: cannot bind /sandbox_api"
    exit 1
}

mount -o bind,ro "$ROOTFS/pkgs" /pkgs || {
    echo "FATAL: cannot bind /pkgs"
    exit 1
}

mount -o bind,ro "$ROOTFS/usr" /usr || {
    echo "FATAL: cannot bind /usr"
    exit 1
}

This avoids depending on whether /usr/sbin is separate from /usr/bin.
This ofc then also mounts libexec or share but i found that do be a non-issue. But if i am mistaken i would gladly be proven otherwise.