Hi Jason, On Sat, 2 Jan 2021 09:02:18 -0500 Jason Conroy 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.