Nspawn has a lot of issues with bind mounts in general. They've never been fixed because pottery doesn't see the point. See for example: https://github.com/systemd/systemd/issues/26897
As a cybersecurity guy, my interpretation is that the requested change could introduce a vulnerability and that there is another potential path to achieve the same result, which should likely be explored first.
Any change that can compromise security needs significant justification, and should come with guards to allow it to be used in those cases where no other alternatives exist, without impacting other cases.
I've mostly used podman and am far from expert, and have long been intrigued by nspawn, so I really would like to understand the rationale.
Any other examples of nspawn mount limitations impacting operations without "workarounds"? Thanks!
Since none of the existing namespaces treat GPUs directly (though perhaps this could be accomplished with cgroup?), this lack of isolation doesn’t surprise me.
While this may be useful for some workloads, the apparent lack of separation gives me pause from a security PoV.
One would hope that podman containers accessing GPUs are otherwise properly constrained to prevent their workloads from using GPU access to gain undesirable access to other hosts resources.
So I am left with my original question: what equivalency to podman, other than invocation convenience, is missing from nspawn? If none, it seems to me that having an awkward invocation in nspawn helps alert the user to the risks hidden by podman's convenience.