Re: Bug#969631: can base-passwd provide the user _apt?
On Sun, Aug 29, 2021 at 11:31:05AM -0700, Russ Allbery wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > I think it's an interesting idea and worth pursuing, but on the face of
> > it it seems that this would end up violating policy 9.2.2:
>
> > "Globally allocated by the Debian project, the same on every Debian
> > system."
>
> > ... because the UID of the _apt user in fact wouldn't be the same on
> > every Debian system, and I can imagine that this might cause trouble
> > somewhere.
>
> My first reaction is that from a strictly Policy perspective you may be
> reading that requirement too strictly.
Certainly possible, and also it's extremely rare for issues about the
global static range to come up at all so we've never really litigated
the exact boundaries of this text.
> I would read that as a statement of intention, not a requirement: the
> intent is for this UID to be the same on every Debian system, but this
> may not be the case in practice due to upgrades. (Which seems
> obviously true or we could never add a new user.)
It's only an issue for users that were already created by some other
package (unless you count the small number of non-system users that
might conflict with any addition, in the absence of "_" prefixes and the
like).
This is also literally the first reasonably compelling case there's been
for adding a new entry to passwd.master in my time as base-passwd
maintainer (since 2002).
> That said, it does feel weird to switch to this sort of static allocation
> and not have a migration strategy for existing systems and leave them on
> an old UID. I know that it's not an explicit design goal of the project,
> but I like the idea that continuously upgraded systems will converge on
> the state that they would get if they were newly-installed, and that seems
> valuable for long-term upgrade support.
>
> My intuition is also that the case where a UID change will cause problems,
> namely:
>
> > I'm mostly just worried about users using file:/ or copy:/ methods
> > and having given _apt access to them, they'd break.
>
> is relatively rare (but maybe I'm wrong about this?), so I'm not sure that
> it outweighs the simplicity advantages of converging on the same UID in
> the long run.
It does feel likely to be rare, but maybe Julian or somebody else on
deity@ can elaborate on whether this is something they've seen much in
the wild.
A UID migration would also require changing the ownership of (at least)
/var/cache/apt/archives/partial, /var/lib/apt/lists/auxfiles, and
/var/lib/apt/lists/partial. Maybe something like "find /etc/apt
/var/cache/apt /var/lib/apt -user _apt" would make this less fragile,
but it still seems like an awkward thing to be doing in base-passwd's
postinst. Helmut said in the original bug report that "libapt always
chowns it to _apt"; I don't know how reliable this is or whether libapt
does it for all the relevant directories. If it's absolutely reliable
then maaaybe we could skip that step, though it feels a bit risky.
> > I think it'd be best if we don't change existing _apt users, but only
> > dealt with new systems for now. I mean we could prompt users about
> > changing the uid
>
> This is certainly a gentler migration, but I think the prompt or providing
> some simple migration path would be valuable so that, in the long run,
> people can converge their systems to the new configuration. Maybe a
> compromise would be to make the prompt have a fairly low urgency level?
> We could then tell people in the release notes that if they're not using
> _apt in some special way, they can dpkg-reconfigure base-passwd and let it
> migrate the UID.
Conceivable. I'm not sure how much that would actually help converge
the mass of systems, numerically.
> > Of course, another approach to the overall problem might be
> > declarative user creation in dpkg, e.g. #685734 and
> > https://wiki.debian.org/Teams/Dpkg/Spec/SysUser. But that's clearly
> > a lot of work, and this change wouldn't preclude it.
>
> This does seem like clearly the right solution in the long run for all
> problems of this sort, though. I wouldn't want to add many statically
> allocated UIDs. (But if anything qualifies for one, _apt is a
> reasonable candidate.)
It's a slightly weird one too, because (aside from the file:/ or copy:/
case) it seems mostly like the sort of user that could be anonymous
outside of the lifetime of an apt process, analogous to systemd's
DynamicUser. But I guess there's no way to do something like that
outside of systemd, much less on systems that don't run systemd at all.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: