all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: 45571@debbugs.gnu.org
Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts
Date: Sat, 02 Jan 2021 04:10:06 +0100	[thread overview]
Message-ID: <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> (raw)
In-Reply-To: <20210102024054.158bb3ba@scratchpost.org>

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	other threads:[~2021-01-02  3:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at>
2020-12-31 18:18 ` bug#45571: Support stable uids and gids for system accounts in a container Jason Conroy
2021-01-01 14:47   ` bug#45571: Support stable uids and gids for all accounts Danny Milosavljevic
2021-01-01 16:26     ` Jason Conroy
2021-01-01 17:36       ` Danny Milosavljevic
2021-01-01 16:20   ` Leo Prikler
2021-01-01 17:50     ` Danny Milosavljevic
2021-01-01 18:44       ` Leo Prikler
2021-01-01 20:22         ` Danny Milosavljevic
2021-01-02  0:25   ` bug#45571: Fwd: " Leo Prikler
2021-01-02  1:40     ` Danny Milosavljevic
2021-01-02  3:10       ` Leo Prikler [this message]
2021-01-02 14:02         ` Jason Conroy
2021-01-02 14:29           ` Leo Prikler
2021-01-02 14:52             ` Jason Conroy
2021-01-02 15:35               ` Leo Prikler
2021-01-02 15:58                 ` Jason Conroy
2021-01-02 14:50           ` Danny Milosavljevic
2021-01-02 15:03             ` Jason Conroy
2021-01-02 15:18             ` Leo Prikler
2021-01-02  1:30   ` Danny Milosavljevic
2021-04-07  7:13   ` bug#45571: Support stable uids and gids for system accounts in a container Brendan Tildesley via Bug reports for GNU Guix
2021-06-10  6:02     ` Arun Isaac
2021-01-02 15:04 ` bug#45571: Support stable uids and gids for all accounts Danny Milosavljevic
2021-01-02 15:25   ` Leo Prikler
2021-01-06 10:03   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=45571@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.