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

Attachment: signature.asc
Description: signature

Reply via email to