Bug#994836: exim: dpkg fatal error due to Debian-exim in statoverride

[Simon McVittie]

On Tue, 19 Oct 2021 at 18:56:15 +0200, Andreas Metzler wrote:
> On 2021-09-21 Wookey <wookey at debian.org> wrote:
> > whilst trying to install build-deps for therion in an unstable chroot
...
> > dpkg: unrecoverable fatal error, aborting:
> >  unknown system group 'Debian-exim' in statoverride file; the system group got removed
>
> no, it is not expected. Both -base and -config will add a Debian-exim
> system user with its own private group in postinst if it does not exist.
> But none of the exim packages ever remove the user.
> 
> So it looks like random system breakage to me. - Isn't user removal
> logged usually?

I think this is a problem specific to persistent schroots (those
that carry over on-disk state from one run to another), such as
type=directory. I saw a similar symptom in a schroot running a Debian
trixie derivative, on a Debian 12 host.

By default, as per /etc/schroot/default/nssdatabases and
/etc/schroot/sbuild/nssdatabases, schroot copies the host system's
/etc/passwd into the chroot during chroot setup. This means it should
be possible to reproduce the issue that Wookey reported like this:

- have a host system (virtual machine will be easiest) that has never
  had Exim installed, for example a fresh bookworm installation

- have a persistent schroot, like this one (it's a trixie derivative):

    [steamrt_steamrt5_amd64]
    description=Steam Runtime 5 development
    directory=/var/chroots/steamrt_steamrt5_amd64
    personality=linux
    groups=sudo
    root-groups=sudo
    preserve-environment=true
    type=directory

- in one schroot session, install Exim: it will add Debian-exim to the
  /etc/passwd in the chroot

- completely end the schroot session (reboot the machine, etc.)
  but keep the on-disk state in (in my case)
  /var/chroots/steamrt_steamrt5_amd64

- open a new schroot: schroot will overwrite
  /var/chroots/steamrt_steamrt5_amd64/etc/passwd with the /etc/passwd
  from the host, which does not contain Debian-exim

- try to run dpkg (for example I ran `apt autoremove`):
  dpkg sees that its statoverride database contains Debian-exim but
  /etc/passwd has no record of that user, and panics

Using transient schroots (those that are documented as implementing
"source chroot" options, such as type=file, type=btrfs-snapshot,
type=zfs-snapshot, type=lvm-snapshot) would likely avoid this problem,
by only copying /etc/passwd during creation of a new chroot session, and
not overwriting it during the lifetime of the session. The cost of this is
that if you *want* state to persist, that's harder to achieve.

I do not see any straightforward way that this could be addressed from
Exim's side, and an equivalent issue would affect any package that creates
a user or group dynamically and uses it for dpkg-statoverride; so maybe this
should be a schroot bug marked as affecting exim4, rather than an exim4 bug.
https://bugs.debian.org/499014 seems to be essentially the same bug, but
for dbus/messagebus rather than exim4/Debian-exim.

    smcv