Le jeudi 25 septembre 2025, 09:03:13 CEST Johannes Schauer Marin Rodrigues a écrit : > Hi, > > Quoting Fab Stz (2025-09-25 08:40:17) > > That's unfortunate given that sbuild+unshare can't be used inside a chroot > > (see the reason in the discussion on #debian-devel dated yesterday) > > there is a lot of text and I don't have time to read through the day's > messages > until I find what you might be referring to.
Snippet (the last part referring to why unshare doesn't work in a chroot) bastif ok, here it is 3.6MiB https://termbin.com/xymj I fear it's not much more informative This one maybe ? unshare(CLONE_NEWUSER) = -1 EPERM (Operation not permitted) zeha (IRC) yeah ok then the next step is to understand the kernel side why that gives EPERM smcv (IRC) you cannot create a new user namespace inside a chroot, because there are situations where you would be able to escape from the chroot by doing that zeha (IRC) well there you go smcv (IRC) a real container manager like incus or podman would probably set up a root directory that is not a chroot so you can use user namespaces (although container managers that want to actually be a security boundary, like podman, often prevent use of user namespaces in some other way, unless told not to be a security boundary with e.g. podman run --privileged) but schroot is not a real container manager, just a chroot environment, which has traditionally been sort-of-half-a-security-boundary in ways that are hard to characterize if your goal is to keep all "development things" inside a sandbox that has a genuine security boundary between it and the host, but you also want that environment to be fully-featured, I'd recommend a virtual machine virt-manager or GNOME Boxes or your favourite alternative to those bastif Thanks for the explanation. ideally I'd like to access some mount points in the "sandbox" (like bind mount). smcv (IRC) at the other extreme, if you completely trust what's in the development environment (hence no security boundary at all), consider podman-toolbox or distrobox > Why would you run sbuild inside a chroot? The whole point of sbuild is to give > you a clean build environment. Why do you need a clean build environment > inside > a clean build environment? To make it very short: my system runs stable (bookwork at the moment) and all development in done in a schroot (testing/unstable) and inside this schroot I run the builds (especially the rust packages which have a specific build wrapper script that is designed to run on unstable). Moreover running sbuild+unshare on the host system would require installing in that case multiple large dependencies, and anyway, running that wrapper script (which calls sbuild) on stable is not supported. In that setup, the only way I found to make the wrapper script work (which calls autopkgtest) is to use a schroot tarball (overlay schroot doesn't work either). > Also: unshare inside unshare is not impossible just not something that has > been > made very user-friendly yet. It's technically possible but just without > quirks. > I haven't spent time on making it user-friendly with sbuild or mmdebstrap > because I fail to see the point. > > Maybe what you want is to run sbuild inside a qemu vm created by debvm? My schroot setup is complex and I had a look at all the VM/container stuff like many other suggested and that seems to make it even more complex. I'm not ready for such a big migration. I'm not even sure I can have an equivalent setup, not to mention the loss of performance and the likely inability to easily share files or bind-mount or access files between the various environments. > Also, if you care about the schroot backend, would you mind helping with > maintaining it? Because interest in it is decreasing it is prone to > bitrotting. That would be nice but in the real world I already have my own set of packages to maintain which is all done on free/hobby time only. Regards Fab
