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

[Jason Conroy <conjaroy@gmail.com>]

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

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?

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

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.

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


> At
> the very least, there should be syntax like
>
> (user-account
>  (inherit sane-system-account-defaults)
>  (name "gdm")
>  (id 92))
>
> Perhaps there could also be a procedure (system-account+group name
> #:key comment uid gid).
>
> Regards,
> Leo
>
>

[-- Attachment #2: Type: text/html, Size: 5457 bytes --]