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 <leo.prikler@student.tugraz.at> 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.

> > > > 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.