Avoid breaking automatic upgrades to Tails 3.9
As noticed thanks to #15419, our devel branch changes the GID of the
-vboxsf:x:112: -monkeysphere:x:113: -debian-tor:x:114:tor-launcher -lpadmin:x:115: +monkeysphere:x:112: +debian-tor:x:113:tor-launcher +lpadmin:x:114: +vboxsf:x:115:
As explained in a774ba2aba7012f3f5bc630b0f3dab8ac696dbd7, "Since the virtualbox 5.2.8-dfsg-7 upload, the virtualbox-guest-utils package depends on virtualbox-guest-dkms". I think this new dependency explains why
virtualbox-guest-utils, that creates the
vboxsf group, is installed later than before.
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
Brainstorming our options:
- ship a patched
virtualbox-guest-utilspackage that removes the added dependency and hope that's enough to fix this instance of the more general problem (while we're at it, we can as well backport the latest version from sid, that adds compatibility with Linux 4.17; too bad, virtualbox is now in stretch-backports which could have given us the opportunity to stop shipping it via our custom APT repo); that's relatively cheap and easy, and surely an acceptable way to postpone the problem, hoping we have more time to address its root cause next time another instance of this problem pops up.
- go back to the hacks from #15424: change UIDs/GIDs via a chroot hook, killing processes as needed; service startup is disabled in the chroot, so in theory only processes started via maintainer scripts and left behind should have to be killed; in practice, that probably boils down to
gpg-agent; so while my concern about killing processes outside of the chroot remains, limiting the kill spree to
gpg-agentprocesses might be safe enough; in our current Vagrant VM, I see no user that has obvious reasons to have
gpg-agentrunning, and indeed I see no such process running during a build. That's also relatively cheap and easy, and most of the work has been done already. It'l be wasted work at some point if overlayfs is not affected by the bug, but well, at least we're covered until #8415 is done.
- find some way to stabilize all UIDs/GIDs (#15407): looks like more work than the two first options, and that work will be wasted if overlayfs is not affected by the bug, which makes this option very unappealing to me.
- complete #8415 (overlayfs) in time for Tails 3.9… assuming overlayfs is not affected by the bug that makes us worry about changing UIDs/GIDs (to be verified on #15689): there's not that much work left to do and we have to do it soon anyway, so clearly it would be the best place to invest our time in; but it's not clear whether it's realistic to do that in the next 1.5 months
I'm currently leaning towards the 2nd option (stabilize just the UIDs/GIDs we want), with the 1st one as a fallback. But depending on how our first shots at #15091 and #15023 go, and on how we distribute the work on these two big tasks, who knows, #8415 might be doable. I'll come back here in a few weeks and depending on our progress on these other fronts, I'll pick the best approach among the options that will be realistic at this point.