bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leo Prikler
Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts
Date: Sat, 02 Jan 2021 04:10:06 +0100
User-agent: Evolution 3.34.2

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.
> 
> That's what Debian supports, too:
> 
> https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes
> 
> > 0-99:
> > Globally allocated by the Debian project, the same on every Debian
> > system. These ids will appear in the passwd and group files of all
> > Debian systems, new ids in this range being added automatically as
> > the base-passwd package is updated.
> > Packages which need a single statically allocated uid or gid should
> > use one of these; their maintainers should ask the base-passwd
> > maintainer for ids.
> 
> [...]
> 
> > 60000-64999:
> > Globally allocated by the Debian project, but only created on
> > demand. The ids are allocated centrally and statically, but the
> > actual accounts are only >created on users’ systems on demand.
> > [...]
You do know, that services such as gdm, pulseaudio, avahi, sshd, mpd,
and others fall into neither region, do you?

> And so does FreeBSD,
> see 
> https://www.freebsd.org/doc/en/books/porters-handbook/users-and-groups.html
> and https://github.com/freebsd/freebsd-ports/blob/master/UIDs for the
> actual registry.
If I had a guixbuilder for every account in that list, that I didn't
need, I'd have a lot of guixbuilders.  Probably more than I could
allocate into a contiguous block under FreeBSD.

> For that matter, IANA does this for ports and many other things.  And
> so on.
> 
> Stable defaults are *good*.
So is leaving room for other configurations.  Some of the bindings we
now consider "default" were only made because other ports were already
claimed.  Not to mention overlaps, such as port 465.

> Right now, the Guix service user user-account record specifies 99% of
> the
> /etc/passwd entry.  I indeed propose to make it 100% for system users
> for Guix
> system services.
What's the remaining 1%?

> > but I shouldn't have to point out why hardcoding ids into those
> > literals is a
> > bad idea.
> 
> You have to point that out to us--especially since Guix service user
> accounts
> of the account-service-type extension can only be instantiated once
> anyway.
Unlike in other systems, where you'd expect people to manually fiddle
around with such files and tragically fail, in Guix your OS config.scm
should reflect the actual state of the system (modulo secrets, that
can't be expressed currently).  If you claim UID 92 for GDM like
FreeBSD does, but people live on installations, that have the old
default of 983 (or any other, depending on the number of guixbuilders
you have), that's going to cause problems.  Perhaps not the same
problems that led to the creation of its activation-service, but still.

That's not to say, that claiming such IDs is *always* bad, just that
it's bad to do so without leaving room for configuration.  I should
likely have worded that better, but at the same time there was context
from which one could have inferred, that I meant hardcoding IDs into
unchanging constants.

>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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]