Here's my initial version of the cleaned up patch for adding a
--chroot-mode=systemd-nspawn. Some things I'm not sure about:
- Should we maybe ping upstream and/or Debian maintainers on
https://github.com/systemd/systemd/issues/13297 to see how hard it
would be to get it fixed so I could remove that whole ugly workaround?
(The workaround also only handles bind mount settings at present -
and for example, I've found that a lot of package builds will require
SystemCallFilter=@memlock due to a lot of crypto libraries and
utilities giving errors if they're denied access to mlock. So I would
probably want to add that to my
/etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.)
- It currently requires giving sudo access for systemd-run, which
essentially would open up execution of anything desired. And the fact
that it requires NOPASSWD (because some of the commands redirect
stdin/stdout) makes things even worse. And even if you restrict it to
e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it would
be possible to fool that with something like "sudo systemd-run -M
unstable-amd64-sbuild -M .host ~/myevilcmd".
- If you want to ignore the small patch in lib/Sbuild/Chroot.pm that's
fine. It's not really related to the systemd-nspawn chroot mode.
- It does add a dependency on libipc-run-perl.
- It would be nice (as a future enhancement) if it would be possible
to configure this backend to start the container in --network-veth
mode and set up the host's side of the veth to forward only traffic
to/from apt-cacher-ng on localhost:3142. Not sure how hard that would
be to accomplish.