On Mon, Apr 4, 2022 at 3:03 PM Luca Boccassi <bl...@debian.org> wrote: > > On Sat, 25 Jan 2020 11:36:09 -0800 Daniel Schepler > <dschep...@gmail.com> wrote: > > Package: sbuild > > Version: 0.78.1-2 > > Severity: wishlist > > > > 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.) > > As mentioned on https://github.com/systemd/systemd/issues/13297 adding > --ephemeral means the machine name has a randomized suffix. Passing -- > machine=$chroot should ensure the config files are picked up as > expected.
OK, if I did that, then would that mean that it's no longer possible to have two sbuild processes using the same base chroot at the same time? (Not that that would be too much of an issue in practice. Though I do admit it's convenient to be able to have my micro_buildd script running one sbuild instance, while on another terminal I can run a manual build with e.g. DEB_BUILD_OPTIONS=nocheck sbuild ... --profiles=nocheck tobootstrap_1.0 .) > > - 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". > > This seems to be used to implement manual synchronization, but this is > not necessary as it's already implemented, see: > > https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready= That's just one use of systemd-run, and a minor one at that. The main use is to run the commands that sbuild needs to invoke, from "apt-get update", "apt-get dist-upgrade", "apt-get source package=ver", "dpkg-source -x filename.dsc", "dpkg-buildpackage" (with --property=PrivateNetwork=yes on this one), "cat *.changes" into a pipe, etc. And as for synchronization, I think I do remember seeing the --notify-ready option. But the man page said the notification would be going to systemd, and I didn't immediately see any way for the sbuild parent process to get that notification or to wait for it. -- Daniel Schepler
