Hi Leo, On Sat, Jan 2, 2021 at 10:35 AM Leo Prikler wrote: > Hello Jason, > Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy: > > On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler < > > leo.prikler@student.tugraz.at> wrote: > > > Hi Jason, > > > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy: > > > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler < > > > > leo.prikler@student.tugraz.at> wrote: > > > > > Hi Danny, > > > > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > > > > Milosavljevic: > > > > > > Hi Leo, > > > > > > > > > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > > > > > Leo Prikler wrote: > > > > > > > > > > > > > > And it indeed is possible to add (uid 4711) in the > > > literal > > > > > and it > > > > > > > > will work > > > > > > > > just fine. > > > > > > > I'm aware you're joking, or at least I hope you are, > > > > > > > > > > > > What? It's perfectly reasonable for a distribution to have > > > > > stable > > > > > > system > > > > > > user ids. > > > > > > > > My reaction to this was not that defaults are bad, but that > > > > dispersing numeric literals throughout the code is. Collectively > > > > these values specify the contents of a registry, so that registry > > > > might as well be located centrally. 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 think it would suffice to raise a condition from shadow.scm, much > > > like my proposed fix for #45570. As far as development is > > > concerned, > > > one could add a check to see, that no conflicts exist between > > > services > > > extending account-service-type. > > > > Assuming that authors of new services tend to choose the lowest free > > ID, is this validation sufficient to ensure that two services checked > > around the same time by different authors won't collide? > No, you'd need to lint the services in the pre-push hook. That would > not be the biggest deal though, we already authenticate the commits and > check whether the NEWS file is broken before pushing, for instance. I > believe it could also be checked without actually instantiating that > system, but don't quote me on that. > Ok, that seems achievable. I would only point out that with a central UID registry you get that validation "for free" in the form of a Git merge conflict. > > > > > 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), with reasonable defaults including > > > numeric > > > > > UIDs and GIDs (at least) for essential services such as GDM > > > sounds > > > > > like > > > > > the best option. WDYT? > > > > > > > > > > Regards, > > > > > Leo > > > > > > > > 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. > > > In this case I'd agree with Danny, that asking users to update two > > > fields to get one service working puts an excessive burden on > > > them. > > > > Leo, I'm not sure what you mean by updating two fields. Are you > > saying that some services already permit manual selection of UIDs? I > > was proposing setting that value in the "users" section of operating- > > system (or elsewhere) rather than setting it in the "services" > > section, but not both places. > As far as I'm aware, no service so far do that, but there are some, > that don't set up the user (e.g. mpd). However, I don't think, that's > the way to go for services like gdm. If you decoupled the gdm user and > group from its service specification, you'd need to modify three > operating-system fields to add gdm as opposed to one. If the gdm user > and group were configuration, you could instead specify them with > modify-services or gdm-service-type itself. > > > Since Guix already uses a central allocator for UIDs and GIDs > > (implemented using simple counters), I was imagining a model where > > the decision is still made centrally, but with different inputs: 1) a > > global mapping from user/group name to default ID; and 2) a similar > > name-to-ID mapping in operating-system where users specify their > > overrides. > I'm not sure how well that'd work together with account-service-type. > You'd have to find a novel way of extending it, that's for sure. > > > > To > > > be fair, I don't even necessarily think, that making the full > > > account > > > configurable is a good idea, unless someone wants to argue, that > > > there's value in potentially giving those accounts shell access. > > > > The thought of making other parts of the account configurable > > occurred to me, but I couldn't come up with any serious use cases > > either. > As far as I'm aware, nologin exists for a good reason. > No arguments there. :) I thought your point was that we don't have a compelling reason to let the end user replace it with something else.