Hi Colin, Quoting Johannes Schauer Marin Rodrigues (2021-10-23 12:13:23) > Quoting Johannes Schauer Marin Rodrigues (2021-08-25 09:54:35) > > Quoting Helmut Grohne (2020-09-06 09:48:26) > > > Another benefit of this change (if a static uid is allocated) is that we > > > improve reproducible installations where currently uids may depend on > > > configuration order. > > > > I'm very interested in having this bug fixed because of the reason above. > > > > And there is yet another use-case that would be solved by the _apt user > > being > > shipped by base-passwd: since apt would no longer require adduser, we would > > automatically get DPKG_ROOT support for Essential:yes packages plus apt. > > > > What do we need to implement this change? I observed that when I apply this > > patch to base-passwd: > > > > diff -Nru base-passwd-3.5.51/passwd.master > > base-passwd-3.5.51+nmu1/passwd.master > > --- base-passwd-3.5.51/passwd.master 2021-07-10 13:57:43.000000000 +0200 > > +++ base-passwd-3.5.51+nmu1/passwd.master 2021-08-24 > > 20:08:52.000000000 +0200 > > @@ -15,4 +15,5 @@ > > list:*:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin > > irc:*:39:39:ircd:/run/ircd:/usr/sbin/nologin > > gnats:*:41:41:Gnats Bug-Reporting System > > (admin):/var/lib/gnats:/usr/sbin/nologin > > +_apt:*42:42::/nonexistent:/usr/sbin/nologin > > nobody:*:65534:65534:nobody:/nonexistent:/usr/sbin/nologin > > > > Then not only will the _apt user be created as expected, but I also observed > > that when upgrading base-passwd on a system with an existing _apt user with > > uid > > 100 from basepasswd 3.5.51 to my patched 3.5.51+nmu1, the uid of the _apt > > user > > remained the same as it should. > > > > Is my observation correct or is anything else missing? > > 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? Thanks! cheers, josch
signature.asc
Description: signature
