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

[Leo Prikler]

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.

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