Re: Bug#969631: can base-passwd provide the user _apt?

[Colin Watson <cjwatson@debian.org>]

On Wed, Nov 24, 2021 at 10:51:50AM +0100, Johannes Schauer Marin Rodrigues wrote:
> Quoting Johannes Schauer Marin Rodrigues (2021-10-23 12:13:23)
> > from the discussion it seems that there are two separate issues.
> > 
> >  1. giving _apt the static uid 42 for new installations
> > 
> > The policy has an argument against it but Russ argues that might be reading the
> > policy requirement too strictly.
> > 
> >  2. switching _apt uid on existing installations
> > 
> > This can break setups relying on file:// and copy:// but David Kalnischkies
> > points out a possible migration strategy.
> > 
> > So other than reading the policy in a very strict way, what speaks against
> > adding apt as uid 42 today and then implement the migration path after the next
> > stable release with warnings of apt as David suggests?
> > 
> > Having _apt with a stable uid does fix problems with uid allocation,
> > dependencies on adduser and DPKG_ROOT today and does not cause any problems on
> > user's systems. Can we do this now as a first step? Is anything else missing
> > other than the trivial diff I wrote above?
> 
> I was looking into writing a patch to base-passwd that makes this possible but
> I need some help from you. As I initially observed, it seems to be easy to just
> let _apt be user 42 for new installations by adding the respective entry to
> passwd.master. Adding that entry will not change the existing _apt user because
> update-passwd will ignore changes in user ids >= 100.
> 
> It becomes tricky if we want to add a mechanism to convert the _apt uid of
> existing installations because the postinst only runs update-passwd if
> --dry-run found a change. But we don't want --dry-run to find a change unless
> the postinst is run with a low debconf priority (like during dpkg-reconfigure).
> But flag_debconf is not set to 1 under --dry-run.
> 
> Do you see a solution that is not too hacky?

Coming back to this thread, I think I've reached the conclusion that
trying to migrate the uid is too risky due to the various weird and
wonderful things that might need to be changed to match, and it makes
more sense to just add the uid and leave existing systems alone.

The patch you posted earlier has a couple of problems (a missing colon,
and I think it makes more sense to set nogroup as _apt's primary group
rather than gid 42 which is in fact the "shadow" group), but I've gone
ahead and committed this:

  https://salsa.debian.org/debian/base-passwd/-/commit/dc157c65936b15b44d359fcbd10481f101bd9c15

I tested this both by making a stock chroot and then upgrading
(preserved existing uid), and by using "sudo mmdebstrap --hook-dir
/usr/share/mmdebstrap/hooks/file-mirror-automount --include
./base-passwd_3.6.1_amd64.deb unstable unstable" to ensure that the new
version is installed first (used uid 42).

Last call for objections before upload!

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]