From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id OE3GE6aY8F/cOAAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 16:00:38 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id yCeND6aY8F9BIAAAB5/wlQ (envelope-from ) for ; Sat, 02 Jan 2021 16:00:38 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D85C4940142 for ; Sat, 2 Jan 2021 16:00:37 +0000 (UTC) Received: from localhost ([::1]:51104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvjKW-0008Ca-LT for larch@yhetil.org; Sat, 02 Jan 2021 11:00:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvjJy-0007uA-II for bug-guix@gnu.org; Sat, 02 Jan 2021 11:00:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48918) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvjJy-0005T8-9h for bug-guix@gnu.org; Sat, 02 Jan 2021 11:00:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvjJy-0002Yh-77 for bug-guix@gnu.org; Sat, 02 Jan 2021 11:00:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096031419727 (code B ref 45571); Sat, 02 Jan 2021 16:00:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:59:01 +0000 Received: from localhost ([127.0.0.1]:60464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvjIz-0002We-3y for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:59:01 -0500 Received: from mail-ed1-f44.google.com ([209.85.208.44]:34137) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvjIw-0002WP-R0 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:58:59 -0500 Received: by mail-ed1-f44.google.com with SMTP id dk8so22471051edb.1 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 07:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DTp8NQfOp+MVeQlyX86qkQhlRG2tPvJKv3kNEVdTFMU=; b=nbYhiafFBLpEY/vCxvVJzZ6tUR/VuBb9B5VxK8AsnWuKlUM0V605eIORC0mjNm9FxM P9Z8TRujC6+lEd2rOJTfum4HN3QWcFn6SHkp/KsJrcKU5R1HzwyAPEgceYET6zsUTFBv ytWA4+FScy3KfeScKKbyizmFI07/8hdKdvhp2q8qXK2zjHO2cyFMptoOKqzsTYsPDmRQ MCN92bkrhWLokfygNdTVx32eNtcZsuKT53/IcfzedB305yIvaYGlvxBRoQiaNHMYFhyp gNAJ1b44GEvDimRA59agTO4eeiC8ZjAibDAMlN3ki4O/wLpqMH2ZuJ4aXkFmYIVQGYr+ 9HSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DTp8NQfOp+MVeQlyX86qkQhlRG2tPvJKv3kNEVdTFMU=; b=DzDo0tafUU8puzkJ7+faJFjZIdnCnLsCsygo733afw/DYbeo/OYV/WAi0SsrXR/s6w 3ibSTu9YITSkQcm+xT4gs7IK4nbBxYnvSWArN1AMlF237KSorq07Ysxix9Rfqc+z8wvb mo1bG89AIoL/WL5QOAZFCrbv7Fj0/ILh2+bsUxzOpwvuBgh0EhpNqNMj1d5Rq7EgRjHI heN1JrYuKKBEp7VkXZmeTARjp/K4jcE1CysqK9Cm/ivIHEsEN0EGh/Rd6WAd/f+b/MRG L8vADoUv+xdzANIMrFiPJ8U//z+zf28dM5SvyxI2BPONjNXGBJ5KHNF55bj2UasHZo6O pDUQ== X-Gm-Message-State: AOAM532yr/QQua81gjK4FYLGzaXP0hsJ3GQ8smQYI/19CEp5CGoFuHFP DEIvjz7H9rcDtsZgIiCtM4M/twmJoVWgQQYI9Sk= X-Google-Smtp-Source: ABdhPJxVVQPpA+DJWte+tUu8Vh+XUYlcPNj2mDbxY1YI856Uok+Nw5dfxMfWCz/lEsBt1WOtsGUYs0qNPYJtwObN4FY= X-Received: by 2002:aa7:c60c:: with SMTP id h12mr64145134edq.145.1609603132913; Sat, 02 Jan 2021 07:58:52 -0800 (PST) MIME-Version: 1.0 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> In-Reply-To: From: Jason Conroy Date: Sat, 2 Jan 2021 10:58:16 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000f77d7505b7eceed0" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 45571@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 0.27 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=nbYhiafF; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: D85C4940142 X-Spam-Score: 0.27 X-Migadu-Scanner: scn1.migadu.com X-TUID: yoQPxcOIruhY --000000000000f77d7505b7eceed0 Content-Type: text/plain; charset="UTF-8" Hi Leo, On Sat, Jan 2, 2021 at 10:35 AM Leo Prikler 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 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. --000000000000f77d7505b7eceed0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Leo,

On Sat, Jan 2, 2021 at 10:35 AM Leo Prikle= r <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> wrot= e:
> > > > >
> > > > > > > And it indeed is possible to add (uid 47= 11) in the
> > literal
> > > > and it
> > > > > > > will work
> > > > > > > just fine.=C2=A0
> > > > > > I'm aware you're joking, or at least = I hope you are,
> > > > >
> > > > > What?=C2=A0 It's perfectly reasonable for a di= stribution to have
> > > > stable
> > > > > system
> > > > > user ids.
> > >
> > > My reaction to this was not that defaults are bad, but that<= br> > > > dispersing numeric literals throughout the code is. Collecti= vely
> > > these values specify the contents of a registry, so that reg= istry
> > > might as well be located centrally. Or at least, there shoul= d be
> > some
> > > mechanism to ensure that two services can't claim the sa= me
> > 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, mu= ch
> > like my proposed fix for #45570.=C2=A0 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<= br> > around the same time by different authors won't collide?
No, you'd need to lint the services in the pre-push hook.=C2=A0 That wo= uld
not be the biggest deal though, we already authenticate the commits and
check whether the NEWS file is broken before pushing, for instance.=C2=A0 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 ma= king
> > user
> > > > accounts an explicit part of service configuration (in = what
> > shape
> > > > may
> > > > still be up for debate), with reasonable defaults inclu= ding
> > numeric
> > > > UIDs and GIDs (at least) for essential services such as= GDM
> > sounds
> > > > like
> > > > the best option.=C2=A0 WDYT?
> > > >
> > > > Regards,
> > > > Leo
> > >
> > > That seems reasonable to me. As for representation, I think<= br> > > there's
> > > value decoupling these settings from a service's own con= fig so
> > that
> > > support for custom UIDs/GIDs remains consistent across servi= ces.
> > In this case I'd agree with Danny, that asking users to updat= e two
> > fields to get one service working puts an excessive burden on
> > them.=C2=A0
>
> 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 o= perating-
> system (or elsewhere) rather than setting it in the "services&quo= t;
> 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).=C2=A0 However, I don't think= , that's
the way to go for services like gdm.=C2=A0 If you decoupled the gdm user an= d
group from its service specification, you'd need to modify three
operating-system fields to add gdm as opposed to one.=C2=A0 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<= br> > 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-typ= e.
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<= br> > > there's value in potentially giving those accounts shell acce= ss.=C2=A0
>
> The thought of making other parts of the account configurable
> occurred to me, but I couldn't come up with any serious use cases<= br> > either.
As far as I'm aware, nologin exists for a good reason.
=

No arguments there. :) I thought your point was that w= e don't have a compelling reason to let the end user replace it with so= mething else.
--000000000000f77d7505b7eceed0--