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

[Simon McVittie]

Control: reassign -1 schroot
Control: retitle -1 schroot: type=directory can make user IDs disappear, causing dpkg-statoverride fatal errors
Control: affects -1 + exim4-base src:exim4

On Wed, 19 Jun 2024 at 12:45:29 +0100, Simon McVittie wrote:
> 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.
...
> "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.

Reassigning to schroot based on that reasoning.

    smcv