From: Jason Conroy <conjaroy@gmail.com>
To: Leo Prikler <leo.prikler@student.tugraz.at>
Cc: 45571@debbugs.gnu.org
Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts
Date: Sat, 2 Jan 2021 10:58:16 -0500 [thread overview]
Message-ID: <CABWzUjXZ3FADpc6pKF+n3a2AB0BRJzSL0-pAY-ykN5ia9iSz6w@mail.gmail.com> (raw)
In-Reply-To: <f74a8e0dc78c7d336487076743d5b4b496106c81.camel@student.tugraz.at>
[-- Attachment #1: Type: text/plain, Size: 5282 bytes --]
Hi Leo,
On Sat, Jan 2, 2021 at 10:35 AM Leo Prikler <leo.prikler@student.tugraz.at>
wrote:
> 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.
>
Ok, that seems achievable. I would only point out that with a central UID
registry you get that validation "for free" in the form of a Git merge
conflict.
> > > > > 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.
>
No arguments there. :) I thought your point was that we don't have a
compelling reason to let the end user replace it with something else.
[-- Attachment #2: Type: text/html, Size: 7233 bytes --]
next prev parent reply other threads:[~2021-01-02 16:00 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
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 [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABWzUjXZ3FADpc6pKF+n3a2AB0BRJzSL0-pAY-ykN5ia9iSz6w@mail.gmail.com \
--to=conjaroy@gmail.com \
--cc=45571@debbugs.gnu.org \
--cc=leo.prikler@student.tugraz.at \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).