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. > - 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= -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
