Package: schroot Version: 1.6.10-4 Severity: wishlist After seeing the capabilities of systemd-run and systemd-nspawn, I wonder if it would make sense to be able to configure an schroot to use these facilities. That would have the advantage of being able to provide greater sandboxing - for example, it would be possible to have stray processes from each command in an schroot session be cleaned up after the individual commands, and in fact that's the default operation mode of systemd-run. (The disadvantage would be a few extra processes in the container, and the fact that the chroot image would have to have at least systemd and dbus installed to support sessions.)
So, roughly what I'm thinking is: Session start: "systemd-nspawn -b -D /path/to/chroot" or "machinectl start <machine-config-name>" and then possibly "machinectl bind <machine-config-name> /path/to/bindpoint" Session execute command: "systemd-run --machine <machine-config-name> --pipe <cmd>" Session end: "machinectl stop <machine-config-name>" Single-command session: "systemd-nspawn -D /path/to/chroot <cmd>" And if schroot also provided a mechanism to pass extra properties for the transient service to the systemd-run command, then I imagine sbuild being able to run something like: # run apt build-dep with network access schroot -c <session-id> apt build-dep pkg # run dpkg-buildpackage without network access, only lo interface schroot -c <session-id> --user=sbuild --systemd-property PrivateNetwork=yes -d /build/pkg dpkg-buildpackage -b -uc At this point, I'm not sure whether it makes sense or not to incorporate this into schroot, or how much work it would be. It would still be nice, though, to have an integration of schroot's capabilities to unpack/update tar files, create LVM snapshots, etc. with systemd's sandbox functionality. (Or some similar sandbox functionality, though I wouldn't see much point in reproducing all that.) -- Daniel Schepler