Hi, Quoting Helmut Grohne (2023-02-05 21:23:18) > What packages would use this beyond mmdebstrap? I see at least chromium's > sandbox using user namespaces for isolation (though with less required > features). Adoption of user namespaces will probably grow.
there is also the autopkgtest of sbuild which I currently run inside qemu to have unshare support during autopkgtest: https://salsa.debian.org/debian/sbuild/-/blob/main/debian/tests/unshare-qemuwrapper The complexity of this script can be much reduced by using debvm. Apart from that, the autopkgtest unshare backend could also be tested in an autopkgtest that supports it. > So initially, it could be as simple as adding this restriction and statically > saying that it is supported by lxc/lxd/qemu and nothing else. > > The other part probably is figuring out how to make it work, which may > be either mmdebstrap bugs or missing features on debci, but diagnosing > this is evidently hard. > > A number of tests that would benefit from this capability can be run with > needs-root or fakechroot (when it works) instead. I'm unsure whether a needs-userns restriction would give me much. Even if that restriction existed, usually I don't want to say "run this test if unshare works" but I want to say "run this if unshare works and this if it doesn't". For example in case of mmdebstrap I'd like to say: - use unshare if it works - use fakechroot otherwise In case of sbuild I'd like to say: - use unshare if it works - run the test inside qemu if it doesn't Since currently I know of no good heuristic to check whether unshare works, I'm running the sbuild autopkgtest always inside qemu and I'm running the mmdebstrap autopkgtest either as root or explicitly using fakechroot. Benjamin Drung attempted to work around this problem in sbuild by checking whether unshare works or not using syscall(&SYS_unshare, $CLONE_NEWNS | $CLONE_NEWUSER); But that is not enough. On salsaci, even if this succeeds, mounting /proc later will fail. The mounting failure can maybe be worked around by using different mount options or bind-mounting if mounting a real proc fails but it showcases that "unshare is working" is not easy to check without actually performing the actions one is interested in. The second thing that Benjamin's merge request shows is, that there is a lot of overhead in determining what test to run: https://salsa.debian.org/debian/sbuild/-/merge_requests/27 Thanks! cheers, josch
signature.asc
Description: signature