bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 4173 bytes --]

Hi Jason,

On Sat, 2 Jan 2021 09:02:18 -0500
Jason Conroy <conjaroy@gmail.com> wrote:

> My reaction to this was not that defaults are bad, but that dispersing
> numeric literals throughout the code is. 

In general that is not exactly true.  What you want is some way to check
the uids for collisions--and putting them into one file only and manually
checking is only one way to do that.  And it's not ideal because then the uid
to use for an account would be in some random file far away from the actual
point of use.  If you mean having both the central registry, and the numeric
literal throughout the code, carry on--I agree.

We also disperse shepherd service names and many other similar things across
literals in the source code of Guix.  Those can cause similar problems.

I agree that it would be better to have a checker, and central registry, for
cross-checking--but right now we don't do that for a lot of other things,
among which are the shepherd service names, dbus service names and dbus
interface names.

This is guile--it could find and lint user account definitions perfectly well,
no matter where they are.  There could be an automated check that the uids are
not duplicated, at compile or lint time.  It would be nice to have such a
checker for the dbus things, too.

But seriously, at this point I don't think any of this in the
currently-discussed form adds enough value to be worth the complexity
and the risk of changing it in the first place.

>Collectively these values specify
> the contents of a registry, so that registry might as well be located
> centrally. 

I agree, if in addition.

(Or if a registry is undesireable, calculate the uids by user name.
These are the possibilities.  If hashing user names is too uncommon on
UNIX elsewhere, I say that we have no /usr or /lib, so we are not exactly doing
common things in Guix because they are common--what we do really depends on the
merits)

>Or at least, there should be some mechanism to ensure that two
> services can't claim the same default ID, otherwise the collision will not
> manifest until somebody instantiates a system with the colliding services.

I agree--that mechanism would need to be added.

> >From the solutions we do have so far, I believe that making user
> > accounts an explicit part of service configuration (in what shape may
> > still be up for debate), 

Not everything needs to be user configurable.  You suggest having these kinds
of things especially user-configurable as a work-around for them not being
stable, right?  Or do you want it in general?

I would like to avoid them here, if only needed for that reason.

(Also, if they are user-configurable, then it's much easier for uid collisions
to happen than if Guix manages them)

So after thinking about it some more, I disagree that that is the best option
for this specific problem.

In my opinion, the best option here is all of these things:

(1) To document that you need to seed /etc/passwd (for Docker etc)
(2) For guix system container to default to the host's /etc/passwd and
(3) For guix system container to add and retain (!) its own /etc/passwd for
accounts only it has (merged together with the host's /etc/passwd for ease
of implementation)

The suggestions I made before that would obsolete /etc/passwd storage got
watered down to a version where they don't obsolete /etc/passwd storage and
thus I oppose doing them in that form.  It would be making the stuff more
complicated--and now you'd have TWO /etc/passwd:

* one /etc/template-passwd (for the uid registry)
(might as well integrate that into guix as a scheme file, though),
* and one /etc/passwd with the currently created users. 

This seems to be excessive just for making uids stable.

> That seems reasonable to me. As for representation, I think there's value
> decoupling these settings from a service's own config so that support for
> custom UIDs/GIDs remains consistent across services.

Is there a need for using custom service UIDs?
I think if so, that is independent of this bug report, which asked for
stable UIDs and GIDs.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]